Оптимизация скорости работы bitrix-сайтов

Разделим оптимизацию на несколько этапов

• Бэкенд и запросы к бд
• Конфигурация и производительность сервера
• Фронтенд - работа со скриптами, стилями, статикой, изображениями и пр.

Подробнее по шагам

1. Ищем узкие места в производительности

В зависимости от фреймворка / цмс существуют разные варианты отладочных консолей / дебаг-панелей.

На примере bitrix протестировать производительность можно в админке - /bitrix/admin/perfmon_panel.php?lang=ru
Результат запуска теста предоставит нам список наиболее загруженных страниц, среднее время их загрузки и количество запросов на каждый хит.

Оптимизируем каждую из нагруженных страниц, сортируя по количеству запросов и времени их выполнения следующим образом:

1. Убираем запросы в цикле (пример ниже)
2. В запрашиваемых данных оставляем только нужные. Т.е. в массиве select должны быть указаны только те поля, с котороми работает скрипт
3. Если время запроса превышает 0.001 секунду - оптимизируем запрос, думаем над созданием индексов
4. Проверяем, настроено ли кэширование и параметры, от которого оно зависит.
5. В случае Битрикса можно использовать их Автокомпозит, которая сохраняет созданые копии страниц в директорию /bitrix/html_pages/ и при загрузке страницы отдает их, подгружая динамический контент в фоновом режиме. В результате пользователю страница отдается моментально

Примеры

Плохо

foreach ($rsObjects as $obj) {
    $params = [
        'filter' => [
            'OBJECT_ID' => $obj['ID']
        ]
    ];
    while ($news = NewsTable::getList($params)->fetchAll()) {
        $arMenu[] = $news['LINK'];
    }
}

Лучше

$objects = [];
foreach ($rsObjects as $obj) {
    $objects[] =  $obj['ID'];
}

$params = [
    'select' => ['LINK'],
    'filter' => ['OBJECT_ID' => $objects]
];
while ($news = NewsTable::getList($params)->fetchAll()) {
    $arMenu[] = $news['LINK'];
}

Далее анализируем лог sql запросов /bitrix/admin/perfmon_sql_list.php?PAGEN_1=1&SIZEN_1=20&lang=ru&by=QUERY_TIME&order=desc,
если готового функционала в системе нет, включаем slowlog (как это сделать - здесь) и работаем с ним.
Выделяем самые медленные запросы и оптимизируем их.

Подробнее про оптимизацию запросов написано здесь.

2. Работаем с настройками сервера

1. Версия Mysql должна быть не ниже 5.7, версия PHP - не ниже 7.0
2. В случае битрикса, проверка /bitrix/admin/site_checker.php?lang=ru не должна выдавать ошибок
3. Желательно наличие акселератора PHP (OPcache, XCache, APC и другого). Лучше всего OPcache

3. Оптимизируем клиентскую часть

Проверяем сайт через:

• https://developers.google.com/speed/pagespeed/insights/ - оценка для мобильных устройств и декстопа должна находится в зелёной зоне
• https://tools.pingdom.com/ - вес страницы не должен превышать 2-3 Mb
• В консоли Chrome в панели audits показатели должны быть выше 60%, подробнее здесь

Что должно быть реализовано:

1. Статическая информация должна кэшироваться браузером (проверить настройки в nginx / .htaccess)
2. Для загрузки картинок, не входящих в первый экран, желательно использовать lazy-load. Это так же касается вторых, третьих и тд картинок на слайдерах
3. Картинки должны быть оптимизированы для веба и отресайзены на нужные размеры
4. Использовать для картинок тэг picture
5. Минификация / обфускация js скриптов
6. Количество подгружаемых на странице js-скриптов должно быть ограничего, т.к. стандартно браузеры могут загружать файлы не более чем в 6-10 потоков с одного хоста.
   Т.е. работать будет быстрее, если собрать несколько мелких js в один большой, чем загружать 40 маленьких отдельно.
   В этом очень большой минус require.js. В идеале сайты нужно переводить на webpack.
   Также как решение мы можем разнести js-скрипты на разные хосты, тогда ограничение будет от 17 до 60 одновременных загружаемых файлов. То же самое касается и картинок.
7. Сторонние стандартные библиотеки лучше подгружать с CDN, т.к. существует вероятность, что браузер пользователя уже их выкачал и закэшировал

Ещё информация о клиентской стороне оптимизации здесь