Оптимизация Core Web Vitals для 1С-Битрикс
Core Web Vitals — три метрики Google: LCP (скорость загрузки главного контента), CLS (стабильность макета), FID/INP (отзывчивость на ввод). С 2021 года они входят в поисковое ранжирование. Для Битрикс-сайтов типичная картина: LCP 4–8 секунд вместо порогового 2.5 с, CLS 0.2–0.5 вместо 0.1, FID/INP выше 200 мс.
Диагностика
Начните с Chrome DevTools → Lighthouse → Performance. Это синтетика, но хорошо показывает узкие места. PageSpeed Insights (pagespeed.web.dev) даёт данные по реальным пользователям из CrUX (Chrome User Experience Report) — это важнее синтетики для оценки реального влияния на поиск.
Для Битрикс-сайтов основные источники проблем:
- LCP: медленный TTFB + большие изображения в главном баннере
- CLS: изображения без
width/height, шрифты безfont-display, динамические блоки (корзина, баннеры) - FID/INP: тяжёлый JavaScript, блокирующие скрипты в
<head>
LCP: критический путь рендеринга
LCP-элемент в Битрикс-магазине — обычно главный баннер (слайдер) или первое изображение в каталоге. Проблема: изображение подгружается через JS после рендеринга страницы.
Решение — preload для LCP-изображения:
<link rel="preload" as="image" href="/upload/banners/main.webp"
imagesizes="100vw" fetchpriority="high">
Добавляется в <head> шаблона. В Битрикс — в header.php главного шаблона или через AddHeadString() в компоненте.
Слайдеры — главный враг LCP. Библиотеки типа Swiper.js загружают JS (100–300 КБ), который откладывает показ первого слайда. Оптимизация: первый слайд рендерить в статичном HTML, JS-инициализацию откладывать через defer или requestIdleCallback.
CLS: смещения макета
CLS ненулевой в Битрикс из-за:
Изображения без размеров. Стандартные компоненты Битрикс часто выводят <img src="..." alt="..."> без width и height. Браузер не знает размер до загрузки и перерисовывает макет. Решение — добавить размеры в шаблон компонента:
// В template.php компонента catalog.element
$width = $arItem['PREVIEW_PICTURE']['WIDTH'] ?? 300;
$height = $arItem['PREVIEW_PICTURE']['HEIGHT'] ?? 300;
echo '<img src="' . $arItem['PREVIEW_PICTURE']['SRC'] . '" '
. 'width="' . $width . '" height="' . $height . '" '
. 'loading="lazy" decoding="async" alt="' . htmlspecialchars($arItem['NAME']) . '">';
Корзина и счётчики. Блок «В корзине: N товаров» или значок корзины в шапке — загружаются AJAX после рендеринга и смещают контент. Резервируйте место через CSS: min-width, min-height для блоков с динамическими данными.
Google Fonts и сторонние шрифты. Без font-display: swap браузер прячет текст до загрузки шрифта (FOIT), затем перерисовывает. Добавьте в CSS:
@font-face {
font-family: 'CustomFont';
src: url('/fonts/custom.woff2') format('woff2');
font-display: swap;
}
JavaScript: блокировка рендеринга и INP
Типичная проблема Битрикс: в <head> шаблона подключаются 10–20 JS-файлов через CJSCore::Init(). Браузер останавливает парсинг HTML при каждом синхронном <script>.
Переход на defer:
<!-- Было (блокирует рендеринг): -->
<script src="/bitrix/js/main/core.js"></script>
<!-- Стало: -->
<script src="/bitrix/js/main/core.js" defer></script>
В Битрикс управление скриптами через \Bitrix\Main\Page\Asset. Переключите вывод JS в footer через Настройки → Главный модуль → Производительность → Переносить скрипты в конец страницы.
INP (Interaction to Next Paint) — заменяет FID с марта 2024. Мерит задержку на все взаимодействия, не только первое. Основные виновники: тяжёлые обработчики событий, синхронные операции в click-хендлерах. Диагностика через DevTools → Performance → INP.
Изображения: WebP и lazy loading
Битрикс умеет конвертировать изображения в WebP через модуль resize_image. Настройка в /bitrix/.settings.php:
'resize_image' => [
'value' => [
'webp' => true,
'webp_quality' => 80,
],
],
После включения функция CFile::ResizeImageGet() возвращает WebP-версию для поддерживающих браузеров. Для старых браузеров — автоматический fallback на JPEG/PNG.
Lazy loading для изображений вне viewport:
<img src="..." loading="lazy" decoding="async" width="300" height="200">
LCP-изображение не должно быть loading="lazy" — это задержит его загрузку. Остальные изображения — можно и нужно.
CSS: критический путь
Битрикс загружает CSS через \Bitrix\Main\Page\Asset::addCss(). Весь CSS выводится в <head>, блокируя рендеринг. Для ускорения первого отображения:
- Выделите критический CSS (стили для visible viewport) и встройте в
<style>в<head> - Остальной CSS загружайте асинхронно:
<link rel="preload" as="style" onload="this.rel='stylesheet'">
Инструменты для определения критического CSS: critical (npm), PurgeCSS для удаления неиспользуемых стилей.
Сроки оптимизации
| Задача | Срок | Влияние |
|---|---|---|
| Диагностика: PageSpeed + DevTools анализ | 1 день | — |
| Preload LCP-изображения, lazy loading остальных | 1–2 дня | LCP −1–2 с |
| Добавление width/height к изображениям | 1–3 дня | CLS → 0 |
| Перенос JS в defer/footer | 1–2 дня | FID/INP −50–200 мс |
| WebP конвертация + оптимизация изображений | 1–2 дня | LCP −0.5–1.5 с |
| Критический CSS | 2–3 дня | LCP −0.5–1 с |
| Оптимизация TTFB (SQL, кеш) | 3–10 дней | LCP −1–4 с |
Полная оптимизация Core Web Vitals для Битрикс-магазина с нуля — 3–5 недель работы. Первые результаты заметны через неделю.