Ускорение и оптимизация сайта на Битрикс

Делать быстрые сайты не просто и только полное выполнение всех требований обеспечивает результаты не менее 90/90. Основное требование к команде: сайт должен быть в «Зеленой зоне» для мобильных устройств (выше 90) и грузиться не более 3х секунд. Данный результат возможно получить только слаженно работая над оптимизацией скорости в составе программиста (backend), верстальщика (frontend) и серверного администратора. Поэтому стандарты разбиты на три ключевые части с тезисным описанием наших подходов.

1. Технические требования к хостингу

1.1. Виртуальная машина Битрикс

Для всех наших клиентов абсолютно всегда мы (как и вендор) рекомендуем виртуальную машину Битрикс. Это компромиссная сборка между удобством и быстродействием. Работа на виртуальной машине в дальнейшем сэкономит огромное количество времени и любой разработчик в любой момент сможет свободно ориентироваться в базовых серверных настройках.

Также для BitrixVM есть готовый скрипт для автоматической настройки всех пунктов, описанных ниже. Если на сервере не BitrixVM, то все это придется делать вручную.

1.2. Настройка кеша статики на 1 год

Кеш статики должен быть настроен на 1 год.

Выполнение данного требования добавляет незначительных 1-2 балла PageSpeed Insights. Подробнее...

1.3. Настройка типа кэширования br

Опытным путем было установлено что тип сжатия br на 30% сжимает лучше, чем gzip. В настройках степени сжатия для br мы указываем значение 6 (всего можно указать значения от 1 до 11). В виртуальной машине Битрикс доступен и gzip и br.

1.4. Настройка библиотек для работы с изображениями

Для сжатия и конвертации картинок PageSpeed Insights рекомендует использовать библиотеки mozjpeg, pngquant, cwebp, как самые эффективные. Данные библиотеки будет использовать модуль slam.image для обработки изображений «на лету» (при интеграции на стороне Битрикс). На сервере должны быть установлены последние версии данных библиотек.

Использование данных библиотек дает значительный прирост в показателях PageSpeed Insights. Подробнее...

1.5. Настройка правильно отдачи картинок формата .webp

Модуль slam.image наряду со сжатием любого изображения всегда создает копию формата .webp. Картинки формата .webp, как правило, сильно «легче» оригинальных форматов, однако не поддерживаются многими браузерами (например, Safari).

Использование данных библиотек дает значительный прирост в показателях PageSpeed Insights. Подробнее...

Для корректного отображения картинок .webp во всех браузерах необходимо внести правки в конфигурацию NGNIX после которых браузерам, поддерживающим технологию WebP будут отдаваться картинки .webp, а остальным оптимизированные копии оригинальных форматов (.jpeg и .png).

• Инструкция по настройке webp NGNIX для BitrixVM
• Статья на habr
• Полные примеры config-файлов для различных конфигураций

1.6. Использование HTTP2

На всех проектах используем HTTP2. Штатно поддерживается в BitrixVM. Насколько быстрее работает не тестили, но в статьях пишут что разница есть.

PageSpeed Insights пока явно не требует HTTP2 и баллы за это не дает.

2. Требования к верстке

2.1. Компонентный подход

Классической и частой ошибкой является создание общих минимизированных файлов стилей и скриптов для всего сайта (для всей верстки). На практике сайты с такой версткой практически всегда разогнать невозможно. А на огромных сайтах с большим количеством страниц и функционала эти сборные файлы со временем разрастаются до нескольких Mb. Это грубая архитектурная ошибка!

Для обеспечения высокой скорости на конкретной странице должны быть подключены только те стили, библиотеки и скрипты, которые используются на текущей странице. Эту проблему решает компонентный подход. То есть создается отдельный файл CSS и отдельный файл JS для каждого блока. Для удобства дальнейшей интеграции в HTML обязательно нужно оставить комментарии для разработчика какие стили подключать и где. Например, наш сборщик делает это вот так:

Для реализации компонентного подхода мы используем сборщик GULP.

Gulp создает отдельные файлы стилей и JS для каждого компонента. Битрикс поддерживает такой подход и впоследствии автоматически собирает все стили и весь JS в один-два файла с именами page_ и template_.

2.2. Critical-стили или ресурсы, блокирующие отображение

Ресурсы, блокирующие отображение страницы это JS, стили и подключение шрифтов. Поэтому:

1. Весь JS в обязательном порядке переносится в конец страницы.
2. Шрифты грузятся инлайново.
3. Стили необходимо подключать правильно. Для первого экрана должен быть создан набор стилей, который гарантирует мгновенную отрисовку первого экрана. Все данные стили должны быть инлайново подключены в в head страницы. Загрузка остальных стилей должна быть перенесена в самый конец страницы. Это делается при помощи простой конструкции:

Если указанный способ по подключению стилей слишком сложен для вашего проекта (или вас), то обратитесь к программистам. У них есть модули, которые могут сделать на Backend.

Использование такой подгрузки значительный прирост в показателях PageSpeed Insights. Подробнее...

2.3. Загрузка картинок Lazy Load

Все картинки в теге <img/> и в styles="background:src«, которые находятся ниже первого экрана должны грузиться при помощи Lazy Load. Грузить абсолютно все картинки через Lazy ошибка! Первый экран должен быть без Lazy, т.к. отрисовка первого экрана дотошно замеряется в секундах и крайне критична (параметр Largest Contentful Paint).

В PageSpeed Insights на данный момент нету прямого пункта, который обязывает подгружать картинки при помощи Lazy Load, но это жизненно важный пункт, который максимально влияет на вес страницы.

2.4. Отображение с выключенным JS

Страница с выключенным JS должна отображаться корректно. А именно:

1. Поскольку все картинки грузятся при помощи Lazy — их быть не должно, за исключением первого экрана.
2. Поскольку все не critical стили перенесены вниз cтраницы, при загрузке пользователь может увидеть часть порванной страницы на мгновение. Для того, чтобы этого не произошло до прогрузки стилей no-critical часть страницы необходимо закрыть прелоадером.

Пример отображения страницы с выключенным JS:

2.5. Требования к верстке широкоформатных слайдеров

Для основных слайдеров на главной странице зачастую используются слайдеры с картинками широкого формата. Как правило, это картинки с разрешением на всю ширину экрана 1920px и шире. Если сделать этот слайдер без должного подхода, то только лишь этот блок снимет не менее 20 баллов PageSpeed .

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

• Обязательным для таких слайдеров является использование тега <picture> для подгрузки разных картинок для разных устройств. Мы всегда используем минимум 2 варианта картинок для слайдера: 1980 для десктопа и 424 для мобайла. Иногда делаем промежуточное разрешение для планшета, если того требует дизайн. Таким образом для мобильного телефона с условно медленным телефоном мы не будем грузить большую тяжелую картинку (которая в 8 раз больше самого телефона), а загрузим маленькую и легкую.
  
• Соседние слайды должны подгружаться только по событию «клик» или «ховер». Если слайдер с автоматической прокруткой элементов, то старт данной прокрутки должен быть отложен на 6 секунд. Таким образом, сколько бы элементов не было в слайдере при первичной загрузке страницы должна грузиться только одна картинка, которая видна посетителям.

Для PageSpeed Insights данный пункт критично важен, т. к. несколько широкоформатных тяжелых картинок могут весить в разы больше, чем вся остальная страница. Особенно от этого страдают показатели мобайл. Подробнее...

2.6. Подгрузка скрытых блоков по событию

Такие элементы сайта как форма обратной связи в модальном окне, выпадающее меню или форма авторизации могут быть вовсе и не задействованы во время посещения вашей страницы. Так зачем же тогда грузить все эти скрытые элементы на страницу сразу?

Показательным примером является форма авторизации в модальном окне. Для валидации подключается JS-библиотека bootstrap.validator, для маски jq.inputmask, да еще JS Recaptcha. Целесообразно загрузить все эти библиотеки только если пользователь открыл модальное окно с формой.

Аналогичного подхода требуют любые другие скрытые объемные блоки. Например:

1. мобильное меню «Гамбургер»,
2. содержимое табов,
3. любое содержимое модальных окон,
4. блоки видео и аудио,
5. тяжелые элементы, открывающиеся по ховеру.

2.7. Верстка слайдеров с использованием skeleton

Если дизайн страницы перегружен, то в рекомендациях PageSpeed неизбежно появляется пункт «Сократите размер структуры DOM». Большое количество блоков на странице дольше анализируется, дольше загружается и дольше отрисовывается. Основными проблемными блоками в таких случаях, как правило являются слайдеры с товарами. Такие блоки, как «Хиты продаж», «Рекомендуемые товары», «Акции» и т. д.

Верстать такие блоки следует при помощи простого стартового шаблона Skeleton. Другими словами, для блока создается 2 состояния:

• Skeleton-шаблон для отображения блока при стартовой загрузки страницы. Обратите внимание, что для SEO крайне желательно оставить ссылки и названия товаров в Skeleton-шаблоне. Иначе товары на данной странице могут не проиндексироваться.
• Обычное состояние, которое загружается при помощи Ajax при скролле к данному блоку.

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

Обычное состояние, которое загружается при помощи Ajax при скролле к данному блоку.

Для PageSpeed Insights данный пункт критично важен. Как пишут в документации, сложная структура DOM усилит использование памяти, замедлит вычисление стилей и увеличит затраты на компоновку шаблонов. Подробнее...

2.8. Отложенный init JS

При последнем обновлении Lighthouse до шестой версии особое значение стало уделяться времени выполнения скриптов. Данный показатель не что иное как Total Blocking Time и ооочень сильно снимает баллы для мобильных устройств. Мы решаем эту проблему запуская все основные скрипты по первому событию на странице: первый клик, скролл, тап или ховер по основному экрану.

Все скрипты, которые можно инициализировать и грузить по персональным событиям подключаются отдельно. На текущий момент на версии Lighthouse 6.3 только благодаря данному пункту возможно делать «зеленые показатели» на мобильных устройствах (и то не всегда).

3. Требования к разработке (Битрикс)

3.1. Требования к шаблону сайта. Пустая страница

Разработка любого проекта всегда должна начинаться с интеграции шаблона сайта или пустой внутренней страницы. На данной странице должен быть реализован полноценный хедер, футер, содержимое в виде обычного текста и полноценный мобайл со всеми элементами.

Интеграции данной страницы необходимо уделить максимальное внимание, т.к. впоследствии любая внутренняя страница вашего проекта будет состоять из пустого шаблона + контент страницы. Если ваш шаблон будет занимать 2Mb, то и любая ваша внутренняя страница будет весить 2Mb + контент. Оптимизируя шаблон сайта вы оптимизируете весь сайт.

Основные моменты:

1. В шаблоне сайта должны подключаться только те стили которые используются на пустой странице (в хедере и футере). Для этих целей верстка делается с использованием компонентного подхода. Как правило, это critical-стили, стили футера и стили мобильной навигации.
2. В шаблоне сайта необходимо подключать только те библиотеки и JS который используется на пустой странице. Грубой ошибкой является подключение в шаблоне JS Яндекс.карты, например, если карта используется только в контактах. Определить минимальный набор подключаемых JS вы сможете проконсультировавшись с верстальщиком проекта.
3. Все картинки необходимо подгружать при помощи Lazy Load. Как правило, это уже будет реализовано на верстке.
4. Если в хедере есть модальные окна, выпадающее меню с огромным каталогом и другие «открывающиеся» элементы, то стоит рассмотреть подгрузку данных элементов по событию, для экономии веса страницы.

После интеграции пустую страницу следует замерить всеми сервисами. Если вы все сделаете правильно, то она должна показать PageSpeed Insights 100\100. Обычно, в наших проектах нам удается оптимизировать шаблон сайта до 200-300Kb.

3.2. Требования по подключению js и css

Все стили необходимо подключать через конструкцию:

JS стоит подключать при помощи конструкции:

Важный момент. Стили и JS шаблона подключаются в шаблоне сайта. Стили и JS компонентов должны подключаться непосредственно из компонентов. Это объемная работа по «Разнесению стилей» не всем понравится, но именно этот подход дает наибольший результат.

Соблюдение правильного подключения стилей и JS обеспечит корректную работу штатных инструментов оптимизации. А это наше все) После всей оптимизации зажмите все галочки и вы получите 95\95. Уберите эти галочки и вы получите 40\70. Проверено!

3.3. Запрет на использование BitrixJS (отключение kernel.js и kernel.css)

Реальность такова, что для использования любой, хоть самой мелкой функции BitrixJS, тянется огромная библиотека, размером в 314kB, вдобавок подключаются все зависимости и дополнительные стили и итого мы будем иметь все 400 kB. 400 kB — это очень много, с учетом, что вся наша главная весит до 1000 kB.

На тему отключения kernel в сети есть множество статей, которые призывают «выпиливать» данный JS при помощи функции preg_replace, но это лишь замедлит загрузку и обязательно что-то сломает.

Kernel стили и JS подключаются только тогда, когда на текущей странице их использует хоть один компонент или модуль. Это может быть модуль аналитики, или галочка «Показывать пользователям сообщение об окончании сессии», умный фильтр или штатный JS корзины — в каждом случае что-то свое.

Отключить эти стили просто и одновременно сложно — не использовать BitrixJS на сайте. Если вы на 100% не пользуетесь им, то kernel грузиться не будут — проверено.

Поэтому в нашей компании действует запрет на использование BitrixJS и любых компонентов и модулей, использующих BitrixJS. В разработке мы используем свой умный фильтр, свой JS добавления в корзину, свое оформление заказа и прочие компоненты, не требующие BitrixJS. Поэтому задача каждого разработчика контролировать отсутствие Kernel вот таким вот способом.

4. Правила работы с изображениями сайта

Все изображения сайта:

• должны подгружаться при помощи Lazy Load, если они не в первом экране;
• должны ресайзиться под отображаемый на сайте размер;
• должны обжиматься с сохранением оптимального качества (если позволяет сервер);
• должен использоваться формат .webp (если позволяет сервер).

Все эти пункты реализует наш модуль картинок slam.image, который обжимает изображения «на лету», а также создает копию картинки .webp.

С картинками следует работать при помощи простой функции:

Данную функцию следует использовать в шаблонах персонально для каждой картинки. Функция работает по аналогии с CFile::ResizeImageGet(), то есть при первом обращении создает копию файла в отдельной папке и впоследствии обращается к данному файлу не пересоздавая его.

Настройки модуля позволяют выбрать оптимальный режим модуля и установить настройки по умолчанию.

Модуль slam.image позволяет на 100% закрыть все пункты про картинки в тесте PageSpeed Insights.

Также для проверки степени сжатия картинок необходимо пользоваться сервисом webspeedtest.cloudinary.com.

4.1. Требования по настройке кеширования на странице

Кеширование в Битрикс это одна из сильных сторон, позволяющее минимизировать нагрузку на сервер. Каждый разработчик SLAM обязан в деталях разбираться в типах кеширования Битрикс, а также в подходах к использованию кеширования.

Разработчик SLAM обязан использовать кеширование всегда и везде. Абсолютно любой запрос должен быть закеширован с оптимальными параметрами обновления кеша. Общее количество запросов с включенным кешем на страницах вашего проекта должно стремиться к нулю. Обычно, это 20-30 системных запросов.

4.2. Допустимое время генерации страницы

Опытным разработчикам известны слабые стороны Битрикс: объемные каталоги свыше 30 тыс. элементов, большое количество свойств, большая вложенность SKU, сложные скидочные системы. Все это работает крайне медленно из-за сложного построения запросов в штатных компонентах Битрикс.

Допустимое время генерации любой страницы на сайте НЕ более 0.5 сек. Это максимальное время задержки, которое пользователь потенциально не заметит глазами. Задержка в 1 сек уже очевидна невооруженным глазом.

Это означает, что сложный функционал необходимо заранее проектировать и продумывать с точки зрения производительности. Это не сложно, если об этом подумать заранее. Иногда достаточно кастомизировать несколько компонентов, иногда приходится использовать кастомный индекс, но в 100% случаев решение всегда есть. Если самому продумать не удалось, старший товарищ всегда поможет.

Контролировать время генерации страницы можно включив отладку и сбросив кеш.

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

4.3. Использование композитного режима

Композитный режим — это «палочка-выручалочка» для проектов с проблемами производительности. Иногда можно сделать все очень неправильно, но включить композит и сайт будет работать достаточно приемлемо.

Однако, композит для своей работы использует Kernel тили и JS (а мы знаем, что это + 400kB к странице). Поэтому на практике для наших сверх оптимизированных проектов композитный режим лишь снимает баллы. Это можно проверить на любом проекте, который в зеленой зоне. Поэтому при разработке проектов полного цикла мы НЕ используем композитный режим. Включение композита у наших проектов отнимает 15-20 баллов.

При поддержке сторонних проектов, которые достались нам по наследству, работа композита обязательна (при корректных настройках, естественно).

4.4. Правила подключения счетчиков и метрики

На практике проверено, что Яндекс.Метрика и другие счетчики снимают в среднем от 10 до 40 баллов PageSpeed , при подключении по инструкции от вендора. Вендор всегда рекомендует подключать счетчики как можно выше в . Однако, такое подключение блокирует отрисовку страницы и замедляет ее. Все всегда пишут об асинхронной загрузке счетчиков, не влияющих на скорость, но по факту это выглядит вот так:

Поэтому подключать счетчики всегда необходимо в конце страницы и загружать их по событию: первый скролл, клик, тап, ховер. Данный тип подключения на несколько процентов искажает аналитику по сайту, но очень значительно экономит время первичной загрузки и добавляет баллы PageSpeed.

В стандартах есть заготовки для правильного подключения счетчиков. Также для этих целей есть модуль slam.yametrika.

Без отложенного подключения счетчиков, к сожалению, сделать зеленую зону на мобайле практически невозможно.

4.5. Правила подключения мессенджеров на сайт

Проблема аналогична проблеме счетчиков и решается похожим образом. Как правило мы создаем заглушку мессенджера и погружаем весь код мессенджера только по клику на эту заглушку. Для посетителя же все выглядит абсолютно естественно.

Также возможно открытие мессенджера по таймеру. Если это необходимо, то стоит поставить задержку не менее 7 секунд.

4.6. Подгрузка тяжелого контента на ajax

Бывают блоки или функционал, которые сильно портят производительность страницы в целом. Это может быть блок с картой в футере или сложный расчет скидочной цены, который выполняется 2 сек. и не меньше.

Как способ оптимизации стоит рассмотреть подгрузку данного блока аяксом при скролле или другом событии. Сервис PageSpeed замеряет только первичную загрузку и при использовании Ajax-подгрузки будет замерять страницу как будто без данного блока вовсе.

5. Рекомендации по конфигурации сервера

Битрикс — тяжелая CMS, это не секрет. Поэтому для комфортной работы сайта нужен хороший хостинг. Для интернет-магазина крайне рекомендованы сервера с HighCPU процессорами от 4500 MHz и NVMе дисками.

При выборе хостинга многие упускают эти важные детали, выбирая между VPS или «облаком» и указывая мощность сервера в «количестве ядер». На практике количество ядер влияет на пропускную способность сервера, но скорость генерации страницы напрямую зависит от частоты процессора. На практике 2 ядра с частотой 4500 MHz будут сильно производительнее 4-х или даже 6-ти ядер с штатной частотой 2500 MHz.

Дисковая система на NVMe дисках это лучшее, что сейчас есть на рынке. От скорости файловой системы зависит параметр чтения/записи данных в БД. У сайтов на 1С-Битрикс всегда много запросов к БД, поэтому этот вопрос крайне важен. Диски NVMe намного быстрее обычных SSD и обеспечивают наибольшую производительность БД.

Проверенные хостинги, с которыми мы партнеримся:

• В РБ: CloudVPS
• В РФ: Timeweb

Ответ: виртуальный или выделенный сервер.

• Идеально: 2×4700 Mhz, ОЗУ 4000 Мб, NVMe 40 Гб.
• Бомж вариант: 4×2700 Mhz, ОЗУ 4000 Мб, SSD 40 Гб.

• fabrikamvk.ru — интернет-магазин,
• skvirel.by — интернет-магазин,
• mebelart.by — интернет-магазин,
• markli.by — интернет-магазин,
• rsn-expo.ru — корпоративный сайт.