Боб Семович

Самое первое - отказаться от неоправданного изменения html. Все эти `data-index` - признак плохого кода. Любой блок должен, по возможности, получаться в JS только один раз, записываться в кеш и работать далее с блоком именно как с JS инстансом.

Второе - разделить глобальное управление и каждый таб в отдельности. Каждый логический блок дожлен быть инстансом класса - тогда значительно легче с этим орудовать и дебажить.

Третье - изменения html максимально выносим в отдельный метод.

Ну и вообще - все действия разбить на блоки в виде методов.

Как разультат:

const TabItemSelector = '.pageNav__tabItem';
const ContentItemSelector = '.pageNav__contentItem';

class TabsManager {
  constructor(navNode){
    this.tabs = [];
    this.activeTab = null;

    this.initFromHtml(navNode);
    this.activateTab(this.tabs[0]);
  }

  initFromHtml (navNode) {
    const headers  = navNode.querySelectorAll(TabItemSelector);
    const contents = navNode.querySelectorAll(ContentItemSelector);

    for (var i = 0; i < headers.length; i++) {
        this.registerTab(headers[i], contents[i]);
    }
  }

  registerTab (header, content) {
    const tab = new TabItem(header, content);
    tab.onActivate(() => this.activateTab(tab));
    this.tabs.push(tab);
  }
  
  activateTab (tabItem) {
    if (this.activeTab) {
        this.activeTab.setActive(false);
    }

    this.activeTab = tabItem;
    this.activeTab.setActive(true);
  }
  
}

const ActiveTabHeaderClass = 'pageNav__tabItem--active';
const ActiveTabContentClass = 'pageNav__contentItem--active';

class TabItem {
    constructor (header, content) {
        this.header  = header;
        this.content = content;
    }
    onActivate (action) {
        this.header.addEventListener('click', () => action(this));
    }
    setActive(value) {
        this.header.classList.toggle(ActiveTabHeaderClass, value);
        this.content.classList.toggle(ActiveTabContentClass, value);
    }
}

document.addEventListener('DOMContentLoaded', ()=>{
  let tabs = new TabsManager(document.querySelector('.pageNav'));
})

Самое сомнительное в этом коде - это, конечно, TabsManager.initFromHtml, где создается взаимосвязь между headers и contents (к примеру, что будет если заголовков табов будет больше, чем детей?). Но это получается из-за верстки.

Как там на Bootstrap — я не знаю, но можно сделать, например, так:

С чем вызвано данное явление?
Оптимизация?
Бюджет?
Или банальная лень?

да да и да)

А для чего? Долго сидя в интернете уже надоедают пёстрые и яркие сайты, с которых побыстрее охото уйти.
Всё больше начинаешь любит спокойный флет стиль типо тостера, хабра, пикабу и т.д

И да, много скриптов и css анимаций могут хорошо так давать нагрузку. Даже не то что у древнего компа, а просто при работе в нескольких окнах \ приложениях. Тем более современные браузеры неплохо так кушают. А если играть во что нибудь в несколько окон (сливать арену в 6 окон в wow), да еще и серфить в инете, все эти скрипты и анимации будут очень дико лагать.

А для клиентов этого делать просто нет времени. Вот у тебя идёт поток сайтов, ты еле успеваешь правки делать. Ну сделаешь ты 1-2 клиентам такие анимации, а они этого даже не заметят, так еще и на половине устройств всё криво работать будет. А платить за это мало кто станет. Если только сайту нужно вызвать какой то wow эффект.

Без разницы, т.к. все данные берутся с Google

Так нужно?

https://codepen.io/web-tech/pen/zVRxeW

Из десктопной версии сделать мобильную версию гораздо проще, чем из мобильной пытаться сделать десктопный интерфейс. Если мобайл-фёрст то про креатив можно забыть.

P.S. мобайл не фёрст, а секьюр и креатив фёрст, потом десктоп, а потом уже мобайл с урезанным функционалом. А мобайл фёд или фоус. Не ведитесь на лозунги толпы, общество часто ошибается. И общественность склонна только клепать штамповки из того, что им скажут.

Давайте попробую по пунктам:

Почему (Mobile First) или (Desktop First) лучше ;
Почему (Mobile First) или (Desktop First) хуже ;

что-то из серии "Что лучше, ложка или вилка?" Ну Вы поняли... Это вопрос исключительно удобства и он напрямую зависит от того, какой у Вас исходный шаблон, и в какую сторону его проще будет адаптировать. Но даже и в этом случае, слово "лучше" тут мало уместно, скорее это вопрос удобства. Мы (в общей сложности человек 50+, от студентов до матёрых разработчиков) взяв за основу ряд параметров с отметкой "нужно делать вот так" от Google PageSpeed провели массу тестов и дискуссий... В результате которых, едино правильного подхода найдено не было. Самый удобный с точки зрения здравого смысла, был такой вариант:
1. Сначала пишем все общие стили, описывающие цвета, шрифты и всю такую ерунду
2. Для каждого диапазона разрешений создаём свой стиль-корректор, который описывает (корректирует) позиционирование элементов, их размеры, размер шрифта и т.д.

Таким образом, как Вы понимаете, "first" вообще отпадает как таковой, получается "and". Но Google'у не нравится такой подход, он просит запихивать "все важные стили" в , и отделить в таком режиме "важные стили" от "не важных" невозможно, т.к. степень "важности" определяется в зависимости от разрешения устройства. Но, говоря исключительно о личном удобстве - удобнее - начинать с мобильной версии, т.к. она априори "меньше" и расширить элемент гораздо проще, чем "слепить более мелкую его версию".

Производительность (Mobile First) или (Desktop First) ;

На производительность это в общей сложности не влияет никак, т.к. Вы банально даже JS'ы можете подгружать нужные на нужное разрешение, по этому вопрос производительности тут вообще сложно обозначить. Хотя, конечно можно опираться на такое условие как "мобильные всегда медленнее чем стационарные устройства", и из этих соображений, если такое условие "сильно вывернуть" и возвести в ранг абсолюта - тоже будет логичнее сначала делать "Mobile first".

Где и каким сайтам подходит (Mobile First) или (Desktop First) ;

MobileFirst по определению идеально подходит тем сайтам, которые изначально (в первую очередь) рассчитаны именно на мобильные устройства, например какой-нибудь "музыкальный сервис онлайн, с возможностью прослушивать MP3'шки в качестве 32-64Кбит, специально для тех у кого кончился трафик и интернет работает с ограничениями скорости". Остальное я описал выше :)

Создавайте гугл бизнес аккаунт и там же делайте представительства во все необходимых регионах. Геморой, но работает.

На сайте придется указывать города в которых хотите продвигаться в тайтле и в контенте страницы. Возможно создавать разные страницы для каждого города.

https://github.com/opencart/opencart/tree/master/upload

Начать стоит с ознакомления со справкой Google - многие моменты хорошо описаны. Также есть видео, где сотрудник Google Андрей Липатцев рассказывает про мультиязычные сайты - вебинар на youtube.

Если вкратце, то можете выбирать любой удобный для вас вариант (поддомен, каталог, отдельный сайт) - в Google Search Console возможно установить таргетинг на конкретную страну в том числе для конкретного раздела на сайте (например /en/).

Обязательно настройте атрибут hreflang для того, чтобы Google лучше понимал связь между версиями страниц на разных языках.

Разницы в ранжировании поддоменов/каталогов нет, поэтому смотрите, с каким из вариантов вы сможете наиболее эффективно работать.

Например, в моей практике была ситуация, когда надо было внедрить hreflang на сайт с 4 языковыми версиями, но из-за того, что URL у каждой версии отличались не только каталогом, но и языком у программистов не сразу получилось настроить это дело корректно из-за особенностей системы. Это вылилось в дополнительные затраты для компании.

p.s. Яндексом буржуи не пользуются, поэтому ориентируйтесь в первую очередь на Google.