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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Использование старых версий PHP и MySQL
2. Не используется/не настроено "1С-Битрикс: Веб-окружение"
Первый пункт, в последнее время, встречается всё реже. Но, если мы обнаруживаем на сайте использование PHP 5.6 — это означает то, что есть большой задел для увеличения скорости сайта после перехода на PHP 7+ (по оценке в панели производительности Битрикс увеличение баллов производительности достигает двух раз). Единственый минус перевода сайта на 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, а также рекомендациям по их использованию отводится отдельная часть в нашем отчете.
обработчики событий (в целом смотрим все подключаемые папки и файлы из init.php)
В идеале, в init.php должны быть только подключения файлов, таких как:

  • константы;
  • обработчики;
  • функции;
  • и т.п.

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

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

Для этого мы переходим на страницу сервиса https://developers.google.com/speed/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 или изображения, указывая на более оптимизированные версии.
Официальная инструкция по установке здесь: https://www.modpagespeed.com/doc/build_ngx_pagespeed_from_source

Для включения/отключения модуля используется опция 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
Говорить о точных цифрах, сколько Pagespeed даст прироста производительности — не корректно. Для каждого сайта — цифра будет сугубо индивидуальна.

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

Как оптимизировать скорость загрузки сайта по 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" и получены следующие результаты:
Примечание: В таблице указаны значения "без отложенной загрузки / с отложенной загрузкой"
Документация Битрикс:
https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=43&LESSON_ID=11907

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

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

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

Ну что — нет невыполнимых задач. Поехали.
Реализация по второму способу немного сложнее. За основу возьмем тот же "bitrix:news.list" и в его шаблоне сделаем следующие изменения:
1. Подключаем jquery (если оно не было подключено ранее) и необходимую нам библиотеку https://github.com/verlok/lazyload
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"> — в этом случае скрипт останется на своем месте.

Уменьшите размер кода 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 Page Speed

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

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

Основные принципы, которых надо придерживаться:

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

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