Оптимизация сайтов (PageSpeed) на базе 1С Битрикс Клиент: proPlastic и proSMD
Ход работы
Основные показатели, с которыми работает PageSpeed – это LCP и FCP.
Главная стратегия по оптимизации этих показателей – неиспользуемые в данный момент пользователем компоненты отображать позже, а то, что ему нужно – выдать как можно скорее.
Длительное отображение LCP объекта
LCP объект – крупнейший элемент на странице, который видит пользователь при обращении к странице. На практике это картинка или баннер.
Такая картинка является маркером для пользователя, что страница началась загружаться. В идеале отрисовке такого элемента не должно ничего мешать, и он должен загружаться сразу при загрузке страницы.
На главной странице двух сайтов LCP объектом выступает слайдер изображений, конкретнее самый первый слайд, который увидит клиент.
Рисунок 1 – LCP объект
Как показал аудит, на сайтах установлено расширение для отложенной загрузки изображений. Оно откладывает загрузку изображений, пока пользователь не увидит область, в которой они находятся.
Проблемой оказалось то, что LCP объект должен загружаться сразу, но расширение откладывало его на потом. Из-за этого показатель загрузки крупного объекта возрастал, что негативно влияло на оценку оптимизации по PageSpeed.
Что было сделано:
- Исключили LCP объект из отложенной загрузки
- Перенесли изображение в тег <img>, чтоб можно было задать приоритет загрузки. Иначе изображение загружалось бы через стили, а это более поздний этап при отрисовке страницы
- Выставили максимальный приоритет первому слайду
- Для следующих слайдов поставили низкий приоритет, так как пользователь их не видит
- На мобильной версии proSMD прогружались изображения для десктопа, но были скрыты стилями. Это забивало трафик ненужными обращениями к серверу, поэтому вывод таких изображений был убран
- Все изображения были сконвертированы в формат webp и обжаты до качества 80, что позволило значительно сократить их размер и уменьшить время загрузки
- Изображения внутри слайдера на мобильной версии сайта имели размер больше ширины стандартного смартфона, поэтому приняли решение пропорционально обрезать такие изображения
- Видео-фреймы из rutube были также отложены, потому что пользователь мог даже не долистать до видео, а rutube при этом подгружал большое количество скриптов и стилей
- Для изображений до сгиба страницы был выставлен средний приоритет, чтобы они не мешали отрисовке главного изображения, но и были следующими в очереди загрузки
Показатель FCP
Показатель FCP отвечает за время, когда начинает отрисовываться страница.
В идеале это должно происходить сразу после получения ответа от сервера. Однако зачастую это невозможно, потому что начало отрисовки могут блокировать:
- скачивание и обработка CSS файлов
- скачивание и выполнение js скриптов
- прочие блокирующие операции
Перед отрисовкой страницы браузеры необходимо понять:
- какие стили применить
- какие скрипты выполнить
Что было сделано:
- Отложили загрузку скриптов, которые не требуют быстрого взаимодействия с пользователем (виджеты, всплывающие уведомления и т.д.)
- Ядро битрикса являлось узким горлышком при оптимизации сайта. Каждая версия переносила наработки из прошлых версий, как снежный ком, увеличиваясь в размерах из-за устаревшего и неиспользуемого функционала. Просто отложить его выполнение влекло за собой ошибки в работе сайта. Однако расширения, которые подгружало ядро, удалось отложить, что значительно сократило время блокировки рендера страницы
- Крупную библиотеку jquery перенесли в низ страницы, чтоб загрузка происходила после отрисовки LCP объекта
- Отложили загрузку квизов и метрики, а также обращений к виджетам bitrix24
- Убрали дублирующиеся обращения к сторонним ресурсам, ведущим к одному и тому же файлу
- Локально загрузили шрифты Google, так как обращение к их серверам более времязатратно
- Убрали preconnect для домена g.fonts, так как нет необходимости заранее подключаться к серверам Google
- Стили виджетов, сторонних сервисов и шрифты были отложены до конца загрузки страницы
Рассинхрон шаблонов для мобильной и десктопной версии сайта
Баг был воспроизведен. Основная причина – некорректная работа режима композита на сайте.
Композит был отключен, после чего проблема исчезла.
Дополнительные работы
- Настроили сжатие статического контента для каждого сайта
- Увеличили время кеширования статического контента
- Добавили в кеширование форматы файлов webp и woff2
Результаты
Для теста производительности были использованы сервисы:
- Google Pagespeed
- Lighthouse
- DevTools Perfomance
Условия тестирования
Сеть:
4G в условиях низкой скорости
Кеш:
отключен
Параметры теста мобильной версии:
Эмулятор смартфона: Moto G Power
Троттлинг CPU: Средние смартфоны (двойной троттлинг)
Было
Рисунок 2 – Замер загрузки страницы
Как видно на изображении, отрисовка LCP объекта занимает порядка 8.45 секунд, что достаточно много. При этом разрыв между FCP и LCP составляет почти половину общего времени загрузки.
- желтые и фиолетовые блоки – стили и скрипты
- зеленые блоки – изображения
Среди изображений находится объект LCP, который на момент замера находится ниже остальных в очереди загрузки.
Стало
Рисунок 3 – Замер после оптимизации
Наше изображение поднялось выше в очереди загрузки, а тяжеловесные скрипты и стили были вынесены ниже во вторую и третью очередь.
Таким образом:
- сначала отрисовывается LCP объект
- затем загружается дополнительные ресурсы
В результате время отрисовки LCP сократилось примерно на 6-7 секунд.
Замеры по PageSpeed
proPlastic
Мобильная версия
Было:
Рисунок 4 – Мобильная версия proPLASTIC до оптимизации
Стало:
Рисунок 5 – Мобильная версия proPLASTIC после оптимизации
Десктопная версия
Было:
Рисунок 6 – Десктопная версия proPLASTIC до оптимизации
Стало:
Рисунок 7 – Десктопная версия proPLASTIC после оптимизации
proSMD
Мобильная версия
Было:
Рисунок 8 – Мобильная версия proSMD до оптимизации
Стало:
Рисунок 9 – Мобильная версия proSMD после оптимизации
Десктопная версия
Было:
Рисунок 10 – Десктопная версия proSMD до оптимизации
Стало:
Рисунок 11 – Десктопная версия proSMD после оптимизации
Категории proSMD
Мобильная версия
Было:
Рисунок 12 – Мобильная версия категории proSMD до оптимизации
Стало:
Рисунок 13 – Мобильная версия категории proSMD после оптимизации
Десктопная версия
Было:
Рисунок 14 – Десктопная версия категории proSMD до оптимизации
Стало:
Рисунок 15 – Десктопная версия категории proSMD после оптимизации
Категории proPLASTIC
Мобильная версия
Было:
Рисунок 16 – Мобильная версия категории proPLASTIC до оптимизации
Стало:
Рисунок 17 – Мобильная версия категории proPLASTIC после оптимизации
Десктопная версия
Было:
Рисунок 18 – Десктопная версия категории proPLASTIC до оптимизации
Стало:
Рисунок 19 – Десктопная версия категории proPLASTIC после оптимизации