Оптимизация скорости загрузки страниц
Для анализа загрузки страниц проверка производилась сервисами:
Выполнены следующие правки для оптимизации загрузки:
Написан скрипт преобразующий формат изображений JPEG/PNG и тд в облегченный WEBP с сжатием без потери качества, преобразование контент менеджером - выполнено. (Исключением являются изображения залитые в описание товаров, минуя инфоблоки, в случае проблем с конкретными страницами рекомендуется перезалить сжатые изображения вручную)
Написан скрипт для автоматического обнаружения важных для страницы файлов оформления (стили) и выставляет приоритет загрузки для сайта. Остальные файлы прогружаются позднее.
Оптимизирована загрузка веб-шрифтов: добавлено свойство font-display: swap для файлов шрифта Manrope. Теперь текст на сайте отображается сразу (системным шрифтом), не дожидаясь полной загрузки основных файлов, что ускоряет визуальную отрисовку страниц.
Оптимизирована метрика LCP (Largest Contentful Paint) на первом экране: для самого крупного визуального элемента (первом ряду товаров в каталоге) отключена отложенная загрузка («lazy load»). Дополнительно внедрена приоритетная предзагрузка (<link rel="preload">), что заставляет браузер скачивать главное изображение параллельно со стилями, полностью исключая задержку рендеринга контента.
Оптимизация и адаптация медиа-контента главных баннеров: Из шаблона компонента вывода баннеров полностью исключена отложенная загрузка (lazy load) для первого слайда, для того, чтобы снизить время отрисовки LCP-элемента на смартфонах.
Включены все доступные настройки главного модуля по оптимизации CSS и JS файлов
Настроен планировщик CRON, Переключено выполнение агентов с хитов на cron
Проверено наличие автокеширования в вызовах компонентов. И количество выводимых элементов на странице, приведено к оптимальным данным
Поизведена проверка подключенных скриптов Метрик. Добавлена обертка для отложенной загрузки данного типа скриптов.
На сайте подключены следующие скрипты, требуется подтверждение актуальности:
| Тип | идетификатор | актуальность |
|---|---|---|
| Meta Pixel Code | 550326348014053 | |
| Meta Pixel Code | 1196103432006104 | |
| google-site-verification | VADZ2BeLmJRRfae2qePXceideSTb3RaGl5d-xeZ44SA | |
| google-site-verification | ocXAZASy-izuMyjB-b7sKpu2GJhHQGmScZNo3yB4jjc | |
| Google Tag Manager | GTM-K6ZJSWT | |
| Google Analytics 4 | G-YS6LRNZLCJ | |
| Yandex.Metrika | 31159686 | |
| calltouch | 33lyk9ee | |
| Hotjar Tracking | 6494156 |
Вопросы по счетчикам:Вопросы по счетчикам:
1) Связаны ли кода Google Analytics и Google Tag Manager? Если да, то код аналитики мы можем удалить, так как данные с сайта все равно будут приходить, сейчас же возможно дублирование данных
2) Какой из Пикселей актуален?
3) Оба кода верификации googleSearchConcole нужны?
Также был произведён анализ времени ответа сервера (TTFB) и нагрузки на базу данных.
С помощью «Монитора производительности» была проведена диагностика страниц каталога. В ходе анализа выявлена критическая проблема: при загрузке некоторых разделов к базе данных выполняется более 1000 SQL-запросов на один хит, что является существенным отклонением от нормы для сайта с индивидуальной разработкой и выступает основным фактором длительного времени ответа сервера.
Однако данная проблема может быть устранена только путём переработки шаблонов и логики готового решения. Поскольку сайт работает на готовом решении, оно выполняет большое количество дополнительных запросов, часть из которых фактически не используется.
Таким образом, для существенного снижения нагрузки и ускорения работы сайта потребуется глубокая переработка готового решения, что по сути означает его частичное переписывание. С учётом объёма работ такой подход связан со значительными временными и финансовыми затратами, поэтому в рамках текущей поддержки его реализация нецелесообразна.
Текущая оценка загрузки страниц
| Сервис PageSpeed Insights | ||
|---|---|---|
| Страница | Desktop | Mobile |
Рекомендации и предложения
Есть вариант с подключением композитного кеша. Для его включения требуется согласование с вашей стороны.
С композитным кешем могут быть связаны следующие риски:
1. Отображение устаревших данных
После внесения изменений данные на странице обновляются не сразу. Например, вы можете изменить цену, наличие или описание товара, но пользователь некоторое время будет видеть старую версию страницы до обновления кеша.
2. Некорректная работа отдельных элементов сайта
Если компонент или шаблон разработан без учета работы кеширования, часть функционала может работать некорректно.
3. Увеличение занимаемого дискового пространства
Композитный кеш сохраняет статические HTML-копии страниц. Если на сайте десятки тысяч товаров, множество фильтров и большое количество URL, размер кеша может вырасти до нескольких десятков гигабайт.
4. Возможные проблемы совместимости с решением Аспро и сторонними модулями
Согласно имеющейся информации, в некоторых случаях композитный кеш может вызывать проблемы в решениях Аспро, а также при работе сторонних модулей.
В отдельных случаях могут некорректно обновляться динамические элементы сайта: счетчики корзины, избранного и сравнения товаров могут отображать неактуальные данные до обновления страницы. Также возможны задержки обновления данных в умном фильтре после импорта или массового изменения товаров. Подобные ситуации обычно связаны с особенностями реализации шаблонов и AJAX-функционала.
Спрогнозировать наличие проблем после включения композита заранее сложно. При тестовом запуске на копии сайта критических ошибок обнаружено не было, однако проверить все возможные сценарии в рамках такого тестирования невозможно.
5. Временное увеличение нагрузки после очистки кеша
После полной очистки композитного кеша происходит так называемый cache warming:
- первые посетители получают страницы без кеша;
- сервер заново генерирует HTML.
На крупных каталогах в этот момент может наблюдаться временное увеличение нагрузки на сервер.
Преимущества включения композитного кеша
1. Существенное снижение TTFB
Без композита при каждом запросе выполняются:
- PHP-код;
- компоненты;
- SQL-запросы;
- обработчики событий.
С композитным кешем сервер отдает готовый HTML из кеша практически без выполнения PHP. Согласно документации Битрикс, это основной механизм ускорения времени ответа сервера.
| Состояние | TTFB |
|---|---|
| Без композита | 1–3 сек |
| С композитом | 50–300 мс |
2. Значительное снижение нагрузки на сервер
После прогрева кеша большинство посетителей:
- не запускают PHP;
- не выполняют тяжелые запросы к базе данных;
- не нагружают инфоблоки.
В результате снижается:
- нагрузка на CPU;
- количество SQL-запросов;
- нагрузка на MySQL;
- количество PHP-процессов.
Для интернет-магазина это может означать снижение нагрузки в несколько раз.
3. Возможность обслуживать большее количество посетителей
Если сейчас сервер условно выдерживает около 50 одновременных пользователей, то после включения композита этот показатель может увеличиться до 200–500 пользователей без изменения тарифа хостинга.
4. Улучшение показателей Core Web Vitals
Композитный кеш напрямую улучшает:
- TTFB;
- FCP;
- LCP.
Пользователь начинает видеть страницу значительно быстрее, а динамические данные подгружаются уже после отображения основного контента.
5. Работает вместе с другими видами кеширования
Не требует изменений бизнес-логики
Быстрее работают тяжелые разделы
Предположительно положительное влияние на СЕО и рост конверсии