Оптимизация сайта под Google PageSpeed

Google PageSpeed — это не про красивую цифру в отчёте, а про поведение реальных пользователей. Для магазина на 1С-Битрикс важны не столько баллы Lighthouse, сколько полевые метрики Core Web Vitals, по которым Google оценивает скорость и от которых зависит позиция в выдаче.

Что измеряет PageSpeed и почему это важно

Инструмент PageSpeed Insights показывает два блока данных, и путать их нельзя. Верхний блок — полевые данные из отчёта CrUX (Chrome User Experience Report): это реальные замеры у посетителей за последние 28 дней. Нижний — лабораторные данные Lighthouse: синтетический прогон в стандартных условиях. Ранжирование Google опирается именно на полевые Core Web Vitals, а Lighthouse нужен для диагностики.

Ключевые метрики, за которыми следим:

• LCP (Largest Contentful Paint) — отрисовка крупнейшего элемента, цель < 2,5 с. На каталоге это чаще всего первое изображение товара или баннер.
• INP (Interaction to Next Paint) — отзывчивость на клики, цель < 200 мс. С марта 2024 заменил устаревший FID.
• CLS (Cumulative Layout Shift) — смещения вёрстки, цель < 0,1. Виноваты изображения без размеров, поздние баннеры, шрифты.

Композит как база быстрого TTFB

Первое, что тянет LCP и Speed Index вниз на Битрикс, — долгая генерация страницы на сервере. Пока PHP собирает шаблон, обращается к базе и инфоблокам, браузер ждёт. Штатный ответ — технология «Композитный сайт» (Настройки → Композитный сайт в админке).

Композит делит страницу на статическую часть (шапка, меню, подвал, каркас), которая отдаётся из кэша почти мгновенно, и динамическую (корзина, авторизация, счётчики), догружаемую AJAX-запросом. В результате TTFB для статики падает до десятков миллисекунд, а браузер начинает рисовать контент, не дожидаясь полной сборки.

Для каталога это самый дешёвый способ выиграть секунду-две на LCP. Важно корректно разметить динамические зоны через CMain::AddBufferContent() и компоненты в режиме композита, иначе персональные данные попадут в общий кэш.

Критический CSS и работа с JavaScript

Render-blocking ресурсы — вторая по частоте причина плохого LCP. Битрикс из коробки умеет объединять и минимизировать статику: Настройки → Настройки продукта → Автокеширование и параметры «Объединять CSS», «Объединять JS», «Минимизировать». Это сокращает число запросов, но не решает проблему блокировки.

Чтобы убрать замечание Lighthouse «Устраните ресурсы, блокирующие отображение», нужен критический CSS — минимальный набор стилей для первого экрана, встроенный инлайн в <head>, а остальное подгружается асинхронно. Приёмы:

• Тяжёлые скрипты (аналитика, чаты, карты) грузить с атрибутами defer или async, а лучше — после события DOMContentLoaded.
• Сторонние виджеты (онлайн-консультант, пиксели) подключать по взаимодействию или таймауту, а не в первой волне загрузки.
• Не подключать jQuery и prototype, если тема их не требует — старые шаблоны Битрикс тянут их автоматически.

Именно «третьи стороны» чаще всего убивают INP: тяжёлый JS блокирует основной поток, и клики обрабатываются с задержкой.

Изображения — главный резерв LCP

На товарных страницах LCP-элементом почти всегда оказывается картинка. Поэтому оптимизация изображений даёт наибольший прирост баллов. План действий:

В Битрикс ресайз удобно делать через CFile::ResizeImageGet() с типом BX_RESIZE_IMAGE_PROPORTIONAL, чтобы не отдавать оригиналы на 3000 px. WebP-конвертацию закрывают модули из Маркетплейса или обработка на уровне Nginx.

Стабильность вёрстки и шрифты

CLS редко ловится в лаборатории, но полевые данные его показывают. Основные источники смещений в каталоге:

1. Изображения и iframe без заданных размеров — резервируйте место через CSS aspect-ratio или атрибуты.
2. Баннеры и промо-полосы, которые вставляются JS-ом после загрузки — задавайте им фиксированную высоту заранее.
3. Веб-шрифты: пока грузится кастомный шрифт, браузер перерисовывает текст. Используйте font-display: swap и <link rel="preload"> для основного шрифта.

Отдельно за INP отвечает объём JS, который выполняется при первом клике. На фильтре умного каталога и в корзине следите, чтобы обработчики не пересчитывали всю страницу синхронно — тяжёлую логику выносите в requestIdleCallback или дробите на части.

Сервер, кэш и HTTP-заголовки

PageSpeed отдельно ругается на «Неэффективную политику кэширования» и «Включите сжатие текста» — это чисто серверные вещи. Что настраиваем на стороне хостинга:

• Gzip/Brotli для HTML, CSS, JS — на уровне Nginx/Apache. Brotli сжимает статику плотнее.
• Cache-Control с длинным сроком для статики (max-age=31536000, immutable) — Битрикс версионирует файлы, поэтому долгий кэш безопасен.
• HTTP/2 или HTTP/3 — мультиплексирование запросов ускоряет загрузку десятков мелких ресурсов.
• Актуальная версия PHP (8.1+) с включённым OPcache — заметно снижает время генерации.

Проверить, что реально доходит до браузера, помогает раздел «Производительность» в панели Битрикс (Настройки → Производительность → Панель производительности): монитор покажет время PHP, число запросов к базе и попадания в кэш. Если TTFB высокий даже с композитом, проблема на бэкенде, а не в картинках.

Порядок диагностики и типичные ошибки

Оптимизацию ведём итерациями, а не наугад. Рабочий цикл:

1. Снимаем базовые полевые метрики в PageSpeed Insights и в Google Search Console (отчёт «Основные интернет-показатели»).
2. В Lighthouse смотрим водопад загрузки: что именно попадает в LCP, какие ресурсы блокируют рендер.
3. Исправляем по одному классу проблем — сначала сервер и композит (TTFB), затем изображения (LCP), затем JS (INP) и вёрстку (CLS).
4. Ждём накопления полевых данных: CrUX обновляется по скользящему окну 28 дней, мгновенного эффекта в поле не будет.

Типовые грабли: измеряют лабораторные баллы вместо полевых; отключают композит ради отладки и забывают вернуть; ставят lazyload на LCP-картинку; подключают три системы аналитики и удивляются низкому INP.

Итог

Оптимизация под Google PageSpeed на 1С-Битрикс — это последовательная работа с TTFB (композит и серверный кэш), LCP (изображения и критический CSS), INP (дисциплина в JavaScript) и CLS (стабильная вёрстка). Ориентируйтесь на полевые Core Web Vitals, а лабораторный отчёт используйте как карту диагностики. Улучшения проверяйте на всех типах страниц и дайте CrUX время накопить свежие данные.

Если нужно быстро довести каталог и корзину до «зелёной» зоны, мы проводим комплексное ускорение: настраиваем композит и кэш, конвертируем изображения, вычищаем блокирующий JS и приводим Core Web Vitals в норму под реальную нагрузку магазина.