разработка

Как оптимизировать сайт и интернет-магазин на Битрикс по рекомендациям Google PageSpeed Insights

Павел Зуев
Технический директор
Оптимизация скорости загрузки сайта по Google Pagespeed Insights
Производительность сайта или его скорость (page speed) — один из важных факторов, напрямую влияющих на конверсию и рейтинг сайта в поисковых системах.

Почему сайту важно иметь хорошие показатели в GPSI:

  1. Когда конкурент находится на расстоянии в один клик, скорость загрузки приобретает во многом решающее значение и напрямую влияет на рост конверсии.
  2. Скорость загрузки сайта — один из важных факторов, который учитывается в алгоритме формирования поисковой выдачи. Выше скорость — выше позиции в поиске — больше трафика.
  3. Если страница сайта загружается медленно при переходе с рекламного объявления в Яндекс.Директ или Google AdWords, пользователь тут же уходит. Оплата за клик списывается, но в статистике переход засчитывается как «отказ». Рост числа отказов ведет к снижению количества показов на рекламных площадках. Выше скорость загрузки (ускорение pagespeed) — больше показов и качественных переходов — ниже стоимость привлечения клиента.
В конце 2018 года Google ужесточил требования к сайтам и внёс коррективы в алгоритмы поискового индексирования и ранжирования. В результате большинство сайтов лишились «зелёной зоны» в Google PageSpeed и сильно «просели» по трафику.

Что изменилось в PageSpeed 5.0

Если ранее при индексировании и оценке скорости сайта упор был на десктопную версию, то теперь на мобильную.

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

В PageSpeed 5.0 страницы загружаются в настоящий браузер Chrome, которым управляет Lighthouse — проект команды, состоящей из разработчиков Google Chrome.

Lighthouse считывает показатели из браузера, ориентированные на оценку того, как пользователь взаимодействует со страницей. Далее автоматически присваивает этим показателям баллы, на основании которых формируется общая оценка сайта.
Сервис Google Pagespeed Insights
К примеру, считывается:

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

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

Самая новая версия Google Page Speed — 8.0

В июне 2021 года сервис PageSpeed Insights опять обновили — теперь доступна версия движка Lighthouse 8. Главные изменения:

  • обновилась математическая калькуляция результата — расчет для FCP, TBT и CLS. CLS и TBT теперь весят больше, а FCP, SI и TTI — меньше.
  • повилась интерактивная карта, фильтрация аудитов по метрикам и новый аудит для политики безопасности контента.
Google прогнозирует, что большинство сайтов останется с прежними показателями или их показатели немного улучшатся.

В Google также показали разницу в оценках между разными версиями Lighthouse.
До обновления:
Lighthouse 6/7​
Lighthouse 6/7
После обновления:
Lighthouse 8.0
Lighthouse 8.0
Отправьте заявку на юзабилити-аудит сайта прямо сейчас и увеличьте конверсию минимум на 20%! Найдём точки роста конверсии и выявим барьеры на пути пользователей сайта.

Как устроен наш процесс по оптимизации сайта под Google PageSpeed Insights и попадания в «зелёную зону»

Изначально сложно спрогнозировать необходимые трудозатраты для достижения желаемых результатов по скорости загрузки сайта на Битрикс и получения необходимого количества баллов от Lighthouse для попадания в «зелёную зону» Google PageSpeed Insights.
Причина одна — у каждого разработчика свои стандарты и регламенты разработки сайта на Битрикс, а у кого-то их нет совсем. И показатели в Гугл PageSpeed — это последнее, на что такой разработчик будет обращать внимание.

Особенно плохо дела обстоят у тех проектов, над которыми успели поработать несколько разных подрядчиков. Нас уже мало чем удивишь, когда к нам на техническую поддержку сайта на Bitrix приходит новый интернет-магазин на Битрикс.
Что влияет на показатели Google PageSpeed Insights:

1. Не оптимизированные изображения (по размеру и весу);
2. Не оптимизированные CSS и JS;
3. Размещение всех JS-скриптов в «шапке» сайта;
4. Проблемы с кешированием (его отсутствие или неправильная работа);
6. Большая глубина и количество элементов в DOM;
7. На сайте не используются:
- современные форматы изображений (в частности «webp»);
- асинхронная и / или отложенная загрузка скриптов.

Это основные проблемы, с которыми приходится сталкиваться чаще всего.
Для того, чтобы дать точную оценку трудозатрат и понять весь масштаб проблем, необходимо провести технический аудит сайта и сервера.

Как правило, если стоит задача улучшить показатели Google PageSpeed Insights (оптимизация Google Page Speed), мы проводим только часть работ комплексного технического аудита сайта, анализируя элементы сайта и сервера, которые могут повлиять на показатели.

По каждому пункту аудита мы пишем отчет, в котором помимо описания найденных проблем даем рекомендации по их устранению.

Аудит сервера и сайта для улучшения показателей GPSI

Аудит проводится на рабочем сайте или копии рабочего сайта на боевом сервере.

Уже на этом этапе иногда возникают проблемы — клиент, в силу ряда причин, не желает или не может дать доступы к своему серверу. Да, мы без проблем можем развернуть копию сайта на своём сервере и провести аудит. Но надо понимать, что результатом аудита сервера будет аудит именно НАШЕГО сервера, который для клиента и для нас не несёт никакой полезной информации.

Вывод: аудит проводим только на сервере клиента.
В рамках аудита сервера мы проверяем:

1. Конфигурацию и программно-аппаратные средства сервера;
2. Текущую загрузку ресурсов сервера;
3. Систему, настройки PHP и MySQL.

Самые распространенные проблемы, влияющие на показатели GPSI, которые мы находим в рамках аудита сервера:

1. Используются старые версии PHP и MySQL;
2. Не используется или не настроено «1С-Битрикс: Веб-окружение».
Первый пункт встречается всё реже. Но если мы обнаруживаем на сайте использование PHP, это означает, что есть большой задел для увеличения скорости сайта после перехода на PHP 7+ (по оценке в панели Битрикс увеличение баллов производительности достигает двух раз). Единственный минус перевода сайта на PHP 7 — после перевода могут появиться (а если честно — всегда появляются) баги. Но так как мы перевели уже не один десяток сайтов, нами выработан алгоритм перевода сайта:

  1. Делаем обновление версии PHP на копии сайта.
  2. Включаем поддержку «mysqli» в «\bitrix\php_interface \dbconn.php» и «\bitrix\.settings.php».
  3. Изменяем версию «mod_php» в файле «.htaccess» с 5 на 7.
  4. Проводим полное тестирование сайта (на этом шаге «бонусом» находим ошибки, которые не связаны с обновлением PHP).
  5. Проводим отладку найденных багов.
  6. Обновляем PHP на боевом сайте и через git переносим правки с тестового сайта.
Единственной проблемой, которая может помешать переходу сайта на PHP 7 — это использование на вашем сайте модулей из Маркетплейс «1С-Битрикс», написанных на PHP 5.6. Но встретить сейчас такой модуль всё труднее, так как многие разработчики выпустили обновления. Но если вам не повезло и ваш модуль не обновился, у вас есть два пути — заменить его аналогом или переписывать код модуля.
Второй пункт «не используется / не настроено «1С-Битрикс: Веб-окружение» — тоже часто встречающийся случай. Удивительно, но на 2 из 3 тестируемых нами серверов не установлено «Веб-окружение» и почти все сервера имеют проблемы.
Установка «1С-Битрикс: Веб-окружение» позволяет решить эти проблемы. Что мы получаем при его установке? Вот цитата из официальной документации Битрикс: «1С-Битрикс: Веб-окружение» — Linux позволяет быстро и с минимальными затратами развернуть оптимальное окружение для работы продуктов и решений «1С-Битрикс» на Linux-платформе CentOS 6/7 (i386, x86_64).
В нашей компании мы используем «1С-Битрикс: Веб-окружение» версии 7.4+ и CentOS 7.
Еще одной «плюшкой» использования «Веб-окружения», начиная с версии 7.4.0, является предустановка модуля «ngx_pagespeed», который содержит набор фильтров, позволяющих повысить скорость сайта. Большое преимущество — для его работы не нужно ничего менять в коде сайта.
Кстати, «1С-Битрикс: Веб-окружение» версии 7.4+ уже включает в себя PHP 7+, поэтому при его применении мы убиваем сразу двух зайцев — получаем оптимизированный сервер с быстрым PHP 7+.

С сервером разобрались, что дальше?

А дальше мы переходим к тестированию сайта — в Панели нас интересуют вкладки «Битрикс» и «Разработка».
Во вкладке «Битрикс» мы получаем список не оптимальных настроек, которые влияют на производительность. Самые распространенные ошибки:

  • проблемы с кешированием,
  • неоптимизированные таблицы БД.
Проверка скорости загрузки сайта на 1С-Битрикс
Если проблемы в базе зачастую решаются в этом же окне нажатием ссылки «Оптимизировать», то проблемы с кешем (если он не просто отключен) требуют более детального изучения.

На вкладке «Разработка» мы собираем список самых нагруженных страниц. Для этого мы запускаем тест на 5 минут (это минимум, чем больше — тем лучше). В зависимости от того, где мы проводим аудит, на боевом сайте или копии:

  • ждем завершения тестирования (если тестируем на боевом),
  • усиленно «ходим» по сайту для более точного отчета по страницам.
Проверка производительности сайта на 1С-Bitrix
Из полученного списка отбираем 20 наиболее нагруженных страниц и обязательно дополняем следующими страницами (если их нет в отчете):

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

  • адрес страницы,
  • время создания страницы,
  • всего SQL запросов,
  • время исполнения запросов,
  • список наиболее «тяжелых» запросов на странице.
ОК, список наиболее «тяжелых» страниц собрали. Что дальше? Приступаем к их детальному изучению и поиску тех участков кода, которые создают нагрузку. Анализ кода мы проводим с помощью профилировщика XHProf.
Какие типы файлов мы изучаем

У компонентов обязательно смотрим:

  • template.php;
  • class.php / component.php;
  • result_modifier.php;
  • component_epilog.php.
В первую очередь обращаем внимание на очевидные проблемы в коде:

  1. Запросы в цикле;
  2. Избыточность данных при выборке, то есть когда применяется пустой $arSelect, а дальше по коду используется всего 1-2 поля из полученных данных;
  3. Кеширование данных.

Мы не формально изучаем код, а смотрим и на «code style» и на саму архитектуру компонента. В разработке, как и в строительстве — правильные архитектурные решения не могут плохо работать :)
Параллельно с изучением шаблонов компонентов и самих компонентов мы обязательно проверяем:

1. Шаблон(ы) сайта — особое внимание мы обращаем на правильное подключение стилей и скриптов.

Если видим такие конструкции:
<link rel="stylesheet" type="text/css" href="style.css">
<script type="text/javascript" src="<a href="script.js">
то это даже не звоночек, а целый колокол, который сигнализирует о том, что на сайте есть проблемы.

Вроде бы, какая разница, как подключены стили и скрипты? Ведь всё же работает. А вот и нет — если подключать их не по «фэншую», через api, то мы лишаемся возможности автоматически применять такие фишки Битрикс, как:

  • объединение CSS файлов;
  • объединение JS файлов;
  • подключение минифицированных версий CSS и JS;
  • перемещение всего JS в конец страницы (после включения данной опции могут возникнуть проблемы с некоторыми скриптами, чтобы запретить их перенос, необходимо при их подключении добавить параметр data-skip-moving="true");
  • создание сжатых копий объединенных CSS и JS файлов (данный метод спорный и может приводить к непредвиденным последствиями, поэтому при его применении необходимо тщательно тестировать сайт).

А применение этих методов существенно влияет на прохождение некоторых аудитов GPSI.

Изучению включенных настроек «Главного модуля» по оптимизации CSS и JS, а также рекомендациям по их использованию отводится отдельная часть в нашем отчете.
2. Обработчики событий (в целом смотрим все подключаемые папки и файлы из init.php)
В идеале, в init.php должны быть только подключения файлов, таких как:

  • константы,
  • обработчики,
  • функции,
  • и тому подобные.

В целом порядок и состав подключений в этом файле напрямую не влияют на скорость сайта, но когда всё лежит «по полочкам», поддерживать сайт проще.

Следующий важный шаг в нашем аудите — это непосредственное тестирование сайта в Google PageSpeed Insights

Для этого мы переходим на страницу сервиса, в единственное поле вставляем url тестируемой страницы и нажимаем «Анализировать».

После непродолжительного ожидания мы получаем результат аудита (отдельно для мобильных и десктопа). Результаты записываем в отчет в виде таблицы.
Чек-лист по тестировании скорости загрузки сайта по Google Pagespeed Insights
Примечание: некоторые показатели могут отсутствовать в новых версиях аудита PageSpeed Insights.

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

Аудит сделали — переходим к составлению плана работ и сметы

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

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

  1. Список работ, необходимых для выполнения оптимизации сайта;
  2. Описание работ по каждому пункту;
  3. Описание возможных рисков по тем пунктам, где они возможны;
  4. Трудозатраты (в часах) по каждому пункту.

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

План составлен, смета утверждена — переходим к практической реализации

Nginx Pagespeed — модуль от Google для Web-серверов Apache и Nginx, который представляет из себя набор фильтров для оптимизации и ускорения загрузки страниц и связанных с ними объектов: CSS, JavaScript, изображений.

Установка модуля возможна на следующие ОС: RedHat, CentOS, Fedora, Ubuntu, Debian.

Если Вы используете виртуальную машину Битрикс, то начиная с версии VMBitrix 7.4.0 от 09.07.2019 г. только для CentOS 7 в сборку nginx 1.16.0 добавлен модуль PageSpeed 1.13.35.2.
Классическая SEO-оптимизация сводится к трём аспектам:

  • уникальный, ориентированный на человека контент;
  • удобство пользования сайтом для пользователя;
  • техническое состояние сайта и скорость его загрузки.

Именно для оптимизации последнего пункта и служит Nginx Pagespeed. Чем выше скорость загрузки страниц, тем выше ранжируемость сайта в поисковых системах.

Модуль PageSpeed улучшает загрузку веб-страницы, изменяя на ней ресурсы, чтобы реализовать лучшие наработки по веб-производительности. Каждое изменение, которое вносит PageSpeed, реализовано через фильтр. Фильтры запускаются в установленном порядке. Каждый фильтр можно включить и отключить в файле конфигурации сервера.
Некоторые фильтры просто изменяют содержимое HTML, например, удаляют лишние пробелы, атрибуты или значения атрибутов. Другие фильтры изменяют ссылки на CSS, JavaScript или изображения, указывая на более оптимизированные версии.
Официальная инструкция по установке здесь.

Для включения / отключения модуля используется опция pagespeed on; или pagespeed off;
Параметры включения модуля можно указывать либо в общем файле настройки nginx — nginx.conf или для удобства в конфиге конкретного сайта.

Сама конфигурация модуля находится в отдельном подключаемом файле. Его содержимое также можно внести в основной конфигурационный файл nginx.conf.
Далее приведены примеры для Битрикс Веб-окружения.
Например, конфиг сайта /etc/nginx/bx/ site_enabled/ bx_ext_ssl_o2k.ru.conf.
В нем включаем модуль и прописываем путь к конфигу с параметрами этого модуля.
pagespeed on; 
include bx/conf/pagespeed.conf; 
Соответственно сам конфиг pagespeed.conf нужно «положить» в /etc/nginx/bx/conf.
Для облегчения настройки PageSpeed имеет три уровня конфигурации:

  • CoreFilters — максимальный набор фильтров, подходящий для работы большинства сайтов. Является уровнем по умолчанию и активируется при запуске PageSpeed без дополнительных настроек.
  • OptimizeForBandwidth — минимальный набор фильтров. В основном оптимизирует и сжимает код.
  • PassThrough — полностью отключает все фильтры.

Уровни определяются директивой pagespeed RewriteLevel.
pagespeed RewriteLevel CoreFilters;
Каждый уровень может быть изменен под себя с помощью добавления нужных или исключения ненужных фильтров.

Директива pagespeed DisableFilters исключает фильтры из конфигурации, а pagespeed EnableFilters добавляет. Фильтры указываются через запятую.

После всех манипуляций не забываем перезапустить nginx: nginx -s reload.
Говорить о точных цифрах прироста некорректно. Для каждого сайта цифра будет сугубо индивидуальна.

При грамотной настройке модуля — отсутствии явных проблем с работой компонентов Битрикса и их кэшированием — при переводе внешних js скриптов на асинхронный вызов, можно с легкостью достигнуть показателя 90-100% как для десктопной версии, так и для мобильного представления.
Отправьте заявку на юзабилити-аудит сайта прямо сейчас и увеличьте конверсию минимум на 20%! Найдём точки роста конверсии и выявим барьеры на пути пользователей сайта.

Как оптимизировать скорость сайта по рекомендациям Google Page Speed Insights

Оптимизация изображений

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

Для примера используется тестовый сайт со следующими характеристиками:

  • чистый Битрикс с демо-магазином;
  • новый инфоблок из 26 элементов (изображения в формате «jpeg» и «png»);
  • средний размер изображений от 200 Кб до 2 МБ;
  • общий вес загруженных изображений — 12,2 МБ;
  • вывод элементов осуществлен через стандартный компонент «news.list» с отключенным кешированием и стандартными настройками.

Показатели до оптимизации. Аудит «Настройте подходящий размер изображений».

Для мобильных:
Оптимизация изображений по Google Pagespeed Insights для мобильных устройств
Для компьютеров:
Оптимизация изображений по Google Pagespeed Insights для компьютеров
1) Сжать изображения

Для этого можно использовать готовые модули с Макретплейса (есть как платные, так и бесплатные), а если изображений немного — воспользоваться online-сервисами, к примеру, https://tinypng.com/

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

Для мобильных:
Сжатие изображений по Гугл Pagespeed Insights для мобильных устройств
Для компьютеров:
Сжатие изображений по Гугл Pagespeed Insights для компьютеров
Применение модуля позволило улучшить показатели в два раза — при том, что оптимизировались не все изображения, участвующие в формировании страницы, а только изображения из инфоблока.

Для сравнения было произведено сжатие двух изображений (одно в формате "JPG", а другое — "PNG") с помощью сервиса https://tinypng.com/.

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

Вывод: если изображений немного и они еще не загружены на сайт, лучше использовать tinypng.com, в остальных случаях — модуль.
2) конвертация / применение изображений в формате «webp»

В настоящее время поддержка данного формата довольно неплохая: https://caniuse.com/#feat=webp.

Для конвертации изображений в формат «webp» можно использовать многочисленные online-сервисы или написать свой класс для конвертации изображений. Мы пошли вторым путем, взяв за основу «CFile::ResizeImageGet».

После конвертации изображений получили следующие показатели:
Примечание: в таблице указаны значения «до конвертации / после конвертации».
После конвертации изображений в «webp» из непройденных аудитов пропал тест «Настройте эффективную кодировку изображений», что является приятным бонусом.

Также видим заметное улучшение показателей теста «Настройте подходящий размер изображений».

Выводы:

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

  1. Настройте подходящий размер изображений,
  2. Настройте эффективную кодировку изображений,
  3. Используйте современные форматы изображений.

Конвертация в webp не сложная процедура, а прирост баллов по GPS и скорости ощутимый.
3) Отложенная загрузка скрытых изображений

Вот что пишет Google по этому поводу:

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

Хорошо, задача понятна. Рассмотрим, как можно ее сделать двумя способами.

Способ №1

Если на вашем сайте версия модуля «UI-библиотека (ui)» не ниже 18.5, то всё совсем просто.
Примечание: в примере использовался стандартный компонент «bitrix:news.list» с немного модифицированным шаблоном.
1. Подключаем vue.js и необходимые зависимости на странице:
\Bitrix\Main\UI\Extension::load("ui.vue");
\Bitrix\Main\UI\Extension::load("ui.vue.directives.lazyload");
2. Сам вывод списка изображений оборачиваем в:
<div id="images_list"></div>
3. Вывод изображения заменяем на:
<img 
	v-bx-lazyload
	data-lazyload-src="<?=$arItem['PREVIEW_PICTURE']['SRC']?>"
	data-lazyload-error-src="https://via.placeholder.com/300/FF0000"
	src="https://via.placeholder.com/300"
	alt="<?=$arItem['PREVIEW_PICTURE']['ALT']?>"
	data-lazyload-dont-hide
/>
ПРИМЕЧАНИЕ: в примере для изображения заглушки используется сервис https://via.placeholder.com — в боевых условиях эти заглушки лучше делать с помощью метода CFile::ResizeImageGet с минимальным качеством или использовать сервис base64-генератор http://png-pixel.com/, и вставлять вот таким образом:
src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mP8Vw8AAoEBfymqrywAAAAASUVORK5CYII=" 
4. В шаблон компонента добавляем:
BX.Vue.create({
    el: '#images_list'  
});
Страница была проверена в PageSpeed Insights, получены следующие результаты:
Примечание: В таблице указаны значения «без отложенной загрузки / с отложенной загрузкой»
Документация Битрикс.

Выводы: если на сайте версия модуля «UI-библиотека (ui)» не ниже 18.5 и в верстке используется список изображений, выводимых с использованием тега img — 100% нужно использовать данный способ, так как настраивается он за 10-15 минут на один шаблон, а показатели GPS увеличиваются значительно.
Способ №2

Данный способ следует применять, если:

  • ваша версия Битрикс не позволяет использовать первый способ;
  • в вашей верстке вы применяете тег «<picture>»;
  • вам принципиально не нравится vue.js

Реализация по второму способу немного сложнее. За основу возьмем тот же «bitrix:news.list» и в его шаблоне сделаем следующие изменения:
1. Подключаем jquery (если оно не было подключено ранее) и необходимую нам библиотеку
CJSCore::Init(array("jquery"));
$this->addExternalJS(SITE_TEMPLATE_PATH . "/js/lazyload.min.js");
2. Вносим изменения в вывод picture:
<picture>
    <source type="image/webp" data-srcset="<?=$arItem['PICTURE_WEBP']['WEBP_SRC']?>">
    <source type="<?=$arItem['PICTURE_WEBP']['CONTENT_TYPE']?>" data-srcset="<?=$arItem['PICTURE_WEBP']['SRC']?>">
    <img class="lazy" data-src="<?=$arItem['PICTURE_WEBP']['SRC']?>" alt="<?=$arItem['PICTURE_WEBP']['ALT']?>">
</picture>
Как видно из кода, потребовалось заменить src на data-src, а srcset на data-srcset (в данном примере еще используется конвертация в «webp»).
3. Добавим скрипт:
$(document).ready(function() {
	var lazyLoadInstance = new LazyLoad({
	    elements_selector: ".lazy"
	});	
});
Страница была проверена в «PageSpeed Insights» и получены следующие результаты:
Примечание: В таблице указаны значения «без отложенной загрузки webp / с отложенной загрузкой webp».
Общие выводы по оптимизации изображений:

  • не полагайтесь на сознательность контент-менеджеров — они очень любят загружать изображения размером по 5000px и по 2Мб+ веса. Лучший способ — подключить и настроить модуль, чтобы всё оптимизировалось «на лету».
  • используйте современные форматы изображений, но только позаботьтесь о том, чтобы в браузерах, которые их не поддерживают, выводились изображения в обычных форматах.
  • используйте отложенную загрузку скрытых изображений — настройка на один компонент занимает 20-30 минут, а польза огромная. При разработке сайтов с нуля сразу закладывайте такой функционал.

Хорошо, с изображениями разобрались, переходим к следующим аудитам:

  1. Устраните ресурсы, блокирующие отображение,
  2. Уменьшите размер кода CSS,
  3. Уменьшите размер кода JavaScript.
Внимание! Описанное далее по тексту решение стоит применять, если вы в силу ряда причин не можете использовать "Nginx Pagespeed".

Устраните ресурсы, блокирующие отображение

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

Первым делом необходимо убедиться, что мы правильно подключаем файлы стилей и скриптов. Для корректной работы они должны быть подключены с помощью API Битрикс.

Вот так правильно:
<? 
use Bitrix\Main\Page\Asset; // подключение css-стилей Asset::getInstance()->addCss("/bitrix/css/main/bootstrap.min.css"); // подключение js-скриптов Asset::getInstance()->addJs(SITE_TEMPLATE_PATH . "/js/myscripts.js"); // подключение произвольных кусков кода (сторонних файлов) Asset::getInstance()->addString("<link rel='shortcut icon' href='/local/images/favicon.ico' />"); ?>
А вот так правильно подключать в шаблонах компонентов:
<? 
$this->getTemplate()->addExternalCss("/local/addcss.css"); 
$this->getTemplate()->addExternalJs("/local/addcss.css"); 
?>
Далее необходимо проделать следующие шаги:
  1. Зайти в настройки главного модуля Настройки > Настройки продукта > Настройки модулей > Главный модуль.
  2. Во вкладке «Настройки» перейти в раздел «Оптимизация CSS».
  3. Включить чекбокс «Переместить весь Javascript в конец страницы».
Оптимизация CSS в 1С-Битрикс
Результат: показатель аудита улучшился с 1,42 сек до 0,46 сек.

Жаль, что в стандартных настройках нет такой же опции по переносу CSS. Но мы знаем обходной путь.

Для этого в header.php вместо $APPLICATION->ShowHead(); вставляем
<link rel="stylesheet" href="/build/assets/styles/app.css"> — основные стили 
echo '<meta http-equiv="Content-Type" content="text/html; charset='.LANG_CHARSET.'"'.(true? ' /':'').'>'."\n"; 
$APPLICATION->ShowMeta("robots", false, true); 
$APPLICATION->ShowMeta("keywords", false, true); 
$APPLICATION->ShowMeta("description", false, true); 
$APPLICATION->ShowLink("canonical", null, true)
А в footer.php добавляем (именно в такой последовательности):
$APPLICATION->ShowCSS(true, true); 
$APPLICATION->ShowHeadStrings(); 
$APPLICATION->ShowHeadScripts();
Результат: показатель аудита улучшился с 0,46 сек до 0,37 сек.

Примечание: если какой-либо js-код не требуется переносить в конец страницы, например google-метрику, то в теге script необходимо указать <script data-skip-moving="true"> — в этом случае скрипт останется на своем месте.
Отправьте заявку на юзабилити-аудит сайта прямо сейчас и увеличьте конверсию минимум на 20%! Найдём точки роста конверсии и выявим барьеры на пути пользователей сайта.

Уменьшите размер кода CSS и Уменьшите размер кода JavaScript

Исправление ошибок в данных аудитах также требует правильного подключения файлов стилей и скриптов.

Если с подключениями всё ОК:
  1. переходим в настройки главного модуля Настройки > Настройки продукта > Настройки модулей > Главный модуль;
  2. в вкладке «Настройки» переходим в раздел «Оптимизация CSS»;
  3. включаем чекбоксы у следующих параметров:
  • Объединять CSS файлы;
  • Объединять JS файлы;
  • Подключать минифицированные версии CSS и JS файлов.

Внимание! Минификатор в Битрикс работает довольно посредственно и большинство сторонних сервисов производят сжатие гораздо лучше.

По этой причине наиболее эффективно будет сжать файлы сторонними минификаторами, добавить в название .min, чтобы получилось к примеру jquery.slider.min.js и «положить» рядом с основным не сжатым файлом jquery.slider.js. В таком случае CMS автоматически подхватит минифицированный файл.
Внимание! Минификатор в Битрикс работает довольно посредственно и большинство сторонних сервисов производят сжатие гораздо лучше.

Сократите размер структуры DOM

Описание аудита: Разработчики браузеров рекомендуют размещать на странице не более 1500 элементов DOM. Наилучшие показатели: глубина дерева — менее 32 элементов, количество дочерних и родительских элементов — менее 60. Сложная структура DOM может увеличить использование памяти, замедлить вычисление стилей и повысить затраты на компоновку шаблонов.

Из-за единого шаблона сайта для всех типов устройств, количество элементов html, стилей CSS, кода JavaScript в верстке сильно увеличивается, что негативно сказывается на загрузке и отрисовке страницы.

Часто функциональные блоки страницы дублируются. Например, меню для мобильных устройств может присутствовать на странице, но визуально не отображаться на десктопе и наоборот.
Чтобы сократить структуру DOM, меню сайта для актуального типа устройства можно подгружать AJAX-ом после загрузки страницы.

В Интернете много примеров, как это сделать.

Показ всего текста во время загрузки веб-шрифтов

Данная ошибка возникает, когда на сайте до загрузки шрифта не отображается контент.
Способ решения этой ошибки:

1. Определяем, какие шрифты вызывают ошибку;
Время загрузки веб-шрифтов в Гугл Pagespeed
2. Находим их в таблице стилей и удаляем/комментируем;
3. Подключаем шрифты инлайново в теге head;
Подключение шрифтов к сайту
4. Прописываем fallback шрифт:
body {font-family: 'FirstFont', 'SecondFont', sans-serif;}
Внимание! В случае с font-display: swap; — обязательно нужно прописывать fallback шрифт.
Так как при значении swap (что в переводе с английского замена, обмен) браузер будет отображать другой шрифт, пока наш основной шрифт не будет загружен полностью.

После всех проделанных манипуляций может появиться эффект «дерганья» текста на доли секунды при загрузке страницы (особенно после очистки кеша). Чтобы минимизировать этот нюанс, необходимо для всех используемых шрифтов сделать предзагрузку. Для этого указываем мета-тег в <head> c параметром preload
Прописываем fallback шрифт
После этого шрифты «предзагружаются» — мы избавились от дерганья.
Скорость сайта в консоли сайта

Настройте предварительную загрузку ключевых запросов

Для того чтобы страница загружалась быстрее, необходимо к тегам загрузки основных стилей <link> добавлять rel="preload".

Минимизируйте работу в основном потоке

Этот аудит тесно связан с «Устраните ресурсы, блокирующие отображение». Поэтому, если мы уже выполнили работы по нему, то показатели должны измениться.
Дополнительно можно сделать асинхронную и отложенную загрузку скриптов.
Вот один из способов отложенной загрузки:
function loadScript(src) { 
var s = document.createElement('script'); 
s.src = src; 
document.body.appendChild(s) 
} 
setTimeout(function() { loadScript('/js/task24807.js') }, 2000);
В качестве параметра src указываем ссылку на файл, который подставляется в созданный элемент — script. Этот элемент подключается в конце тега body.

При помощи setTimeout откладываем загрузку на две или больше секунды.
Вызывать функцию рекомендуется в подвале сайта, в конце тега body, после основной загрузки страницы.

Данную функцию мы использовали на одном сайте, где скрипт сильно резал показатели. И у нас получилось улучшить показатель по данному аудиту на 3 секунды.

Выводы по оптимизации под Google PageSpeed

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

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

Основные принципы:

  • оптимизируйте изображения, css и js-код;
  • старайтесь подключать меньше файлов — только самые необходимые на странице. И подключайте их правильно;
  • правильно настроенное кеширование — это уже половина успеха.
Получайте полезный контент от KISLOROD в любой из мессенджеров
При переходе в одну из указанных социальных сетей, вы автоматически соглашаетесь с политикой конфиденциальности
Спасибо, что дочитали до конца.
Если информация была полезна, поделитесь статьёй. Вам не сложно, нам приятно ;)

Рекомендованные статьи

Скачайте 17 точек роста и 100 + чекеров для роста конверсии и прибыли интернет-магазина
При переходе в одну из указанных социальных сетей, вы автоматически соглашаетесь с политикой конфиденциальности
Мы проанализировали ведущие интернет-магазины, результаты исследований, свой опыт и собрали важные моменты в одно руководство. Делаем e-commerce лучше, поэтому не только пользуемся сами, но и делимся с вами.
Выберите удобный мессенджер и получите чек-лист прямо сейчас: