Боб Семович

Индусы со времён динозавров делают так:

<?php if (!isset($_SERVER['HTTP_USER_AGENT']) || stripos($_SERVER['HTTP_USER_AGENT'], 'Сюда прописать имя юзерагента google page speed') === false): ?>
// сюда код аналитики
<?php endif; ?>

увидели 100 из 100? Теперь удалите костыль и перестаньте заниматься тупыми замерами, раз гугл не посчитал нужным сообщить своему замерщику время кеширования своей же аналитики :)

Очищать не надо. Это нормальный процесс работы системы с оперативной памятью.
В линуксе такая модель работы с оперативной памятью. Чтобы память не простаивала страницы, которые были прочитаны помещаются в кеш. Это ускоряет операции повторного чтения. Когда память понадобится процессам этот кеш будет или вытеснен в swap или дропнут. В общем used\free не однозначные показатели и надо смотреть картину в целом.
Вот интересная статья на эту тему:
markelov.blogspot.ru/2009/01/linux-procmeminfo.html

Правильно ли я указал dns записи?

Вроде да.

Если ваш почтовый сервер отправляет почту с IP 1.2.3.4 и представляется как mail.domain1.com, то должны соблюдаться два условия

• A запись mail.domain1.com должна указывать на 1.2.3.4
  
• PTR запись для 1.2.3.4 должна указывать на mail.domain1.com
  

Т. е. всё (HELO сервера, FQDN и PTR) должно просто соответствовать друг-другу.

MX записи для всех этих доменов при этом не обязательно должны указывать именно на mail.domain1.com, но можно и так.

SPF лучше использовать SoftFail (~all). Например
v=spf1 a mx ~all
Про DKIM и DMARC тоже стоит почитать (они чуток посложнее SPF).

А-запись -- отображение доменного имени в IP адрес.
MX(Mail eXchange)-запись -- имя почтового сервера(ов) для домена.
CNAME-запись -- отображение доменного имени в другое доменное имя.
PTR-запись -- отображение IP адреса в доменное имя.
Использование ссылки на CNAME в качестве имени почтового сервера считается недопустимым (RFC2181).

При доставке почты МТА используют MX и A записи для домена, вторую -- если нет первой.

Допустим у вас есть сервер с IP адресом 1.2.3.4 и он предоставляет некоторые сервисы, к которым вы желаете обращаться по символьному имени myserver.com.
Для этого вы вносите в ДНС А-запись вида
myserver.com. A 1.2.3.4

Если вы собираетесь принимать почту для этого домена на том же сервере, то вам, в принципе, ничего более для этого не надо, поднимаете почтовый сервер (MTA) и наслаждаетесь жизнью.
Однако, если вы собираетесь ещё и отправлять почту, то начинаются подводные камни.
Серверы-получатели отправляемой вами почты могут захотеть, чтобы присутствовала PTR-запись для вашего IP адреса 1.2.3.4, отображаемая в то же имя. В случае если у вас один домен, один сервер и провайдер не возражает, то прописываете PTR (так называемую обратную зону) и наслаждаетесь жизнью:
1.2.3.4 PTR myserver.com.

Если хостинг-провайдер не идёт на сотрудничество (что редко), либо у вас на одном сервере обслуживаются более одного домена, либо это планируется, то жизнь перестаёт быть такой простой и незатейливой. В этом случае и выходит на сцену схема с MX записями.
Исходная ситуация та же: у вас есть сервер с IP 2.3.4.5, обслуживающий домен myservice.org (его веб-сервер, например) и отрправляющий/принимающий для него почту. А-запись:
myservice.org. IN A 2.3.4.5
Теперь мы создаём ещё одну А-запись, имя не принципиально, но лучше выбрать говорящее, типа mail или mx:

mail.myservice.org.  A 2.3.4.5
или
mx.myservice.org. A 2.3.4.5

То есть, фактически, ваш сервер получает второе имя, которое ссылается всё равно на тот же IP адрес.
Теперь это новое имя вы делает почтовым сервером для вашего домена внесением ещё одной записи:
myservice.org. MX 10 mail.myservice.org.
Число после "MX" -- это приоритет данного сервера на случай, если их несколько, чем меньше число, тем приоритетнее сервер.
После этого действия почта должна начать ходить (при условии правильной настройки вами MTA на вашем сервере).
почти всегда, за исключением особо привередливых борцов со спамом.

Там же есть кеширование. Напрягает конечно, но не сильно. Если вы не конвертируете 4k изображения.

Самое первое - отказаться от неоправданного изменения 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.