Оптимизация Core Web Vitals на Битрикс: зелёные LCP, CLS и INP

Когда сайт на Битрикс краснеет по Core Web Vitals, первое искушение — поставить универсальный модуль ускорения, нажать пару галочек и ждать зелёных метрик. На бумаге это выглядит дёшево и быстро. На практике плагин лечит симптомы вслепую: он не знает, какой именно ресурс держит ваш LCP, что конкретно прыгает в вашей вёрстке и какая задача JavaScript утяжеляет INP. Он применяет общие приёмы ко всем подряд, поэтому результат частичный и нестабильный, а иногда плагин ломает вёрстку или конфликтует с темой и модулями. Ниже разбираем, чем адресная работа по трём метрикам отличается от галочек и почему она держит зелёную зону годами.

Почему метрики нельзя лечить общими галочками

Core Web Vitals — это три разные метрики с разными причинами, и каждая требует своего подхода. LCP упирается в один критический ресурс и в скорость ответа сервера. CLS складывается из конкретных элементов, которые сдвигают вёрстку. INP растёт из конкретных длинных задач JavaScript. Универсальный плагин не различает эти причины: он включает минификацию, ленивую загрузку и отложенный JS оптом, надеясь, что что-нибудь поможет. В лучшем случае метрики чуть улучшаются, в худшем — отложенный скрипт ломает важный виджет, а ленивая загрузка задевает именно ту картинку, которая и есть ваш LCP, и метрика становится хуже.

Адресная работа устроена иначе. Мы сначала находим причину каждой красной метрики, а потом точечно её лечим. Если LCP держит главный баннер — добавляем ему preload и приоритет, а не отключаем всё подряд. Если CLS даёт блок отзывов без зарезервированного места — фиксируем его высоту, а не трогаем остальную вёрстку. Если INP утяжеляет тяжёлый сторонний скрипт — дробим задачу или откладываем именно его. Такой подход не только надёжнее доводит до зелёных, но и не создаёт новых проблем.

Как мы доводим LCP до зелёного

LCP — самая заметная для пользователя метрика: это время до показа главного блока, ради которого человек и пришёл. Мы начинаем с поиска критического ресурса: чаще всего это крупное изображение или баннер на первом экране, реже — заголовок, который ждёт загрузки шрифта. Дальше работаем по нескольким направлениям. Добавляем preload критического ресурса, чтобы браузер начал грузить его как можно раньше. Переводим изображения в современные форматы и задаём адаптивные размеры, чтобы на мобильных не грузилась десктопная картинка. Снимаем приоритет и ленивую загрузку с главной картинки, чтобы она не оказалась в очереди за второстепенными файлами. Ускоряем ответ сервера через кэширование, чтобы первый байт приходил быстрее. В результате главный блок показывается в пределах зелёного порога даже на мобильных и медленных сетях. Если страница ещё и тяжёлая по серверной части, помогает общее ускорение сайта на 1С-Битрикс, которое разгружает время ответа.

Как мы убираем скачки CLS

CLS — про стабильность вёрстки. Высокий показатель означает, что контент прыгает при загрузке: текст съезжает вниз, когда сверху подгружается баннер, кнопка уезжает из-под пальца, а пользователь промахивается. Причина почти всегда в элементах без зарезервированного места. Изображения без заданных размеров раздвигают контент, когда наконец загружаются. Рекламные баннеры и виджеты появляются с задержкой и толкают всё вниз. Шрифты при подмене меняют высоту строки. Мы лечим это резервированием места: задаём размеры изображениям и контейнерам заранее, бронируем высоту под баннеры и виджеты, настраиваем загрузку шрифтов так, чтобы резервный и основной шрифт занимали одинаковое место. После этого вёрстка перестаёт прыгать, а CLS уходит в зелёную зону.

Как мы разгружаем INP

INP пришёл на смену старой метрике отзывчивости и оказался строже: он измеряет задержку отклика на действия за всю сессию, а не только при первой загрузке. Высокий INP означает, что после клика или ввода интерфейс зависает на доли секунды, потому что главный поток занят длинной задачей JavaScript. Источники — тяжёлые карусели, виджеты чата, счётчики аналитики, сторонние скрипты, которые выполняются разом и блокируют браузер. Мы разгружаем главный поток: дробим длинные задачи на короткие части, чтобы между ними браузер успевал отвечать на действия, убираем дублирующиеся и ненужные скрипты, откладываем загрузку некритичного кода до момента, когда он действительно нужен. Часть этой работы пересекается с фронтенд-оптимизацией и Core Web Vitals в целом, поэтому делаем её системно, а не точечными заплатками.

Почему важно мерить по реальным пользователям

Главная ошибка при работе с Core Web Vitals — ориентироваться только на лабораторный балл. Лабораторный прогон показывает один заход с фиксированными настройками на быстром канале, а Google ранжирует по полевым данным CrUX — это реальные пользователи за последние 28 дней, включая мобильные устройства, слабые сети и старые телефоны. Поэтому бывает, что в лаборатории всё зелёное, а в Search Console URL помечены как медленные. Мы всегда работаем по полю: снимаем метрики из CrUX, смотрим на 75-й перцентиль и при необходимости подключаем RUM-мониторинг, который собирает метрики прямо у ваших посетителей. Так мы лечим то, что реально мешает людям, а не то, что показывает синтетика. Если нужна независимая оценка состояния, поможет аудит Core Web Vitals и PageSpeed на Битрикс с подробным разбором всех трёх метрик.

Когда хватит точечной правки, а когда нужна системная работа

Мы не навязываем всем максимальный объём работ. Иногда сайт почти в зелёной зоне, и достаточно поправить одну-две метрики на ключевых шаблонах — добавить preload главной картинки и зарезервировать место под пару блоков. В других случаях красные все три метрики, шаблонов много, а на сайте десятки сторонних скриптов — тогда нужна системная работа по всему сайту с подключением мониторинга. На бесплатном замере мы снимаем текущие метрики, показываем, какая из них в красной зоне и насколько глубоко, и честно говорим, какого объёма работ хватит для вашего случая. Решение принимаем по фактическим данным, а не по желанию продать побольше.

Как мы защищаем результат от регрессий

Доведённые до зелёных метрики легко уронить новым релизом: маркетолог добавил тяжёлый баннер, разработчик подключил ещё один скрипт, дизайнер вставил блок без размеров — и CLS снова красный, а INP пополз вверх. Поэтому мы не просто один раз правим метрики, а помогаем удержать их. Подключаем мониторинг, который отслеживает Core Web Vitals по реальным пользователям и сигнализирует, когда метрика выходит из зелёной зоны. Подсказываем, как поставить проверку Web Vitals в процесс релиза, чтобы новый код не ронял показатели незаметно. Фиксируем в документации, что и зачем меняли, чтобы команда поддерживала результат и не возвращала старые проблемы.

Возражения, которые мы слышим чаще всего

«У нас и так быстрый сайт, в PageSpeed зелёная цифра». Лабораторная цифра PageSpeed и полевые Core Web Vitals — разные вещи. Высокий балл в синтетике не гарантирует зелёных метрик в Search Console, потому что ранжирование идёт по реальным пользователям. Мы смотрим именно поле, и часто за зелёным лабораторным баллом скрываются красные полевые LCP или INP на мобильных.

«Метрики — это для SEO, на заявки не влияет». Влияет напрямую. Медленный показ главного блока и прыгающая вёрстка прогоняют посетителя ещё до того, как он увидит предложение, а зависающий после клика интерфейс мешает оформить заявку. Зелёные Web Vitals — это не только сигнал для поиска, но и удобство, которое доводит людей до целевого действия.

«Плагин уже стоит, разве этого мало». Плагин делает базовые вещи, но не различает причины ваших красных метрик и иногда сам создаёт проблемы. Мы проверяем, что именно даёт плагин, оставляем полезное, убираем вредное и доделываем адресно то, что галочки не закрывают.

Чем оптимизация метрик выгоднее редизайна

Когда сайт краснеет по Core Web Vitals, иногда возникает мысль переписать его заново на быстром фреймворке. На деле это дорого, долго и рискованно: новый сайт теряет накопленные позиции, привычные сценарии и интеграции, а гарантии, что он окажется быстрым, никто не даёт. В большинстве случаев доводить метрики выгоднее на текущем сайте. Мы не трогаем бизнес-логику и контент, а работаем точечно с тем, что мешает LCP, CLS и INP: ресурсами, вёрсткой и скриптами. Это в разы дешевле редизайна, проходит без остановки сайта и сохраняет позиции, которые уже заработаны. Редизайн оправдан, когда сайт устарел и по другим причинам, но как способ починить метрики он почти всегда избыточен.

Ещё одно преимущество адресной оптимизации — предсказуемость. Мы заранее видим по диагностике, что именно держит каждую метрику, и можем оценить эффект конкретной правки до того, как её внесём. Поэтому работа идёт от причины к результату, а не методом проб: сначала самые тяжёлые узкие места с наибольшим влиянием на 75-й перцентиль, потом остальное. Такой порядок даёт зелёную зону быстрее и дешевле, чем сплошная переделка наугад.

Типичные узкие места на сайтах Битрикс

За годы работы с 1С-Битрикс мы видим повторяющиеся причины красных метрик. Главный баннер или слайдер на первом экране грузится без приоритета и держит LCP. Каталог товаров отдаёт изображения в тяжёлых форматах и без адаптивных размеров, поэтому на мобильных страница весит лишнее. Подключённые модули и виджеты тащат за собой собственные скрипты, которые выполняются разом и утяжеляют INP. Блоки отзывов, карты и сторонние формы появляются без зарезервированного места и дают скачки CLS. Композитный кэш настроен не на все страницы, и сервер долго отдаёт первый ответ. Каждое из этих узких мест мы знаем, как лечить аккуратно, не ломая привычную работу сайта и не вмешиваясь в ядро.

Что вы получаете по итогу

Результат работы — все три метрики Core Web Vitals в зелёной зоне на 75-м перцентиле по реальным пользователям, а не только в лаборатории. URL уходят из категории «требуют улучшения» в зелёную зону в Search Console, что помогает позициям, а живой опыт посетителей становится лучше: главный блок показывается быстро, вёрстка не прыгает, интерфейс отвечает без задержки. Вы получаете понятный отчёт с метриками до и после, описанием внесённых изменений и рекомендациями, как удерживать зелёную зону в дальнейшем. Все правки внесены без вмешательства в ядро Битрикса, поэтому обновления платформы проходят без конфликтов, а результат остаётся стабильным.

С чего начать

Начните с бесплатного замера. Пришлите адрес сайта — мы снимем текущие LCP, CLS и INP по CrUX и Search Console, покажем, какая из метрик в красной зоне и насколько глубоко, и предложим план доведения до зелёных под ваш случай. Замер бесплатный, и по его итогам вы получите честную картину: что мешает метрикам, какой объём работ нужен и за какой срок все три показателя уйдут в зелёную зону. Обсудим ваш сайт — и сделаем его быстрым и стабильным для людей и для поиска.