Core Web Vitals и скорость: что чинить разработчикам, чтобы росли позиции и конверсия

Скорость в 2026 году перестала быть «приятным бонусом». Она стала фильтром. Страница может выглядеть идеально, но если главный блок появляется через 4 секунды, а кнопка «Купить» реагирует с задержкой, поиску и пользователю всё равно. Я обычно объясняю это команде так: контент без скорости похож на витрину за грязным стеклом. Его видно, но покупать не хочется.

Core Web Vitals — три метрики про реальный опыт пользователей: загрузка, отзывчивость, стабильность. Google оценивает их по полевым данным на 75-м перцентиле, то есть «как у большинства, а не у счастливчиков на Wi-Fi». Нормы простые: LCP до 2,5 с, INP до 200 мс, CLS до 0,1. Если хотя бы одна метрика красная у заметной доли трафика, вы теряете и позиции, и конверсию.

Диагностика за 30 минут, чтобы не лечить «всё подряд»

• Смотрите поле, а не только Lighthouse. В PageSpeed Insights берите Field data и сегменты Mobile и Desktop, держите в голове скользящее окно 28 дней.
• В DevTools Performance фиксируйте LCP element и Long Tasks, включайте Web Vitals overlay.
• Снимайте водопад сети и смотрите, что блокирует первый экран: CSS, шрифты, hero-картинка, JS-бандл, TTFB.
• Проверяйте три шаблона: главная, листинг, карточка. Дальше всё масштабируется.

LCP, цель 2,5 секунды

LCP почти всегда упирается в «герой» на первом экране. На услугах это баннер 800–1200 КБ, на e-commerce — фото товара в слайдере, который тянет полстраницы. Лечится не шаманством, а дисциплиной ассетов и серверной части.

Делайте так. Готовьте hero в AVIF или WebP и держите реальный вес 80–180 КБ на мобиле, отдавайте размеры через srcset. Указывайте width и height, чтобы браузер сразу планировал место. Прелоадьте LCP-картинку и ключевой шрифт, для изображения ставьте fetchpriority="high" и не прячьте его за lazy-load. Убирайте render-blocking: критический CSS инлайн на 10–20 КБ, остальное грузится позже.

Серверная часть тоже решает. Для SSR держите TTFB стабильно в диапазоне 200–400 мс на большинстве запросов, иначе LCP не взлетит. Работают кэш HTML для анонимных, микро-кэш на 1–5 секунд, Brotli, HTTP/2 или HTTP/3, CDN на статику и картинки.

INP, цель 200 миллисекунд

INP показывает, как быстро страница отвечает на клики, тап и ввод. Порог «зелёного» — 200 мс, «красного» — 500 мс Самая частая причина — длинные задачи JS. В профайле это выглядит как пачка Long Task по 150–800 мс во время скролла или клика по фильтру.

Тут я обычно говорю разработчикам прямо: сначала режем ненужный JavaScript, потом обсуждаем «оптимизацию». Убирайте тяжёлые виджеты, которые не дают продаж, или переносите их на after-interaction. Делите бандл по маршрутам и компонентам, чтобы на карточке не жил код личного кабинета. Тяжёлые вычисления уводите в Web Worker, особенно сортировки, фильтрации, расчёты доставки.

Отдельная зона боли — рендер и гидрация. Чистый CSR даёт поздний первый экран, тяжёлый SSR даёт дорогую гидрацию и провалы INP на первом взаимодействии. Нормальный компромисс выглядит так: SSR для первого экрана, затем частичная гидрация, «острова» интерактивности, отложенные компоненты, постепенная загрузка фильтров и личных блоков. На низких устройствах это часто даёт минус 100–200 мс по INP без потери функциональности.

Плюс мелочи, которые дают ощутимый эффект. Ставьте passive listeners на touch и wheel. Используйте event delegation вместо сотен обработчиков. Не гоняйте синхронный layout thrash в обработчиках кликов, сначала собирайте данные, потом одним батчем меняйте DOM.

CLS, цель 0,1

CLS — визуальная стабильность. Хорошо до 0,1, плохо выше 0,25. В коммерции CLS бьёт прямо в деньги. Человек тянется нажать «Заказать», а блок смещается из-за баннера или шрифта.

Фиксы, которые закрывают основную долю проблем:

• Всегда задавайте размеры для изображений, видео, iframe, рекламных блоков. Нет размеров — будет сдвиг.
• Резервируйте место под баннеры, куки-плашки, чат-виджеты. Вставка «сверху и внезапно» почти гарантирует красный CLS.
• Шрифты. Делайте preload на woff2, subset по глифам, font-display: swap или optional, и подбирайте fallback с похожими метриками.
• Не меняйте высоту элементов после рендера, особенно карточек в листинге. Скелетоны держите по размерам финального контента.

Кэш, CDN, изображения

Я люблю правки, которые делаются один раз и улучшают всё. Ставьте CDN для статики и картинок, задавайте cache-control: public, max-age и immutable для хэширующихся файлов. Делайте оптимизацию картинок на лету через image proxy, если контент грузят менеджеры и никто не думает о весе. Добавляйте preconnect к критичным доменам, если медиа живут отдельно.

Контроль, чтобы скорость не умерла через месяц

Ставьте бюджеты: LCP до 2,5 с на 75-м перцентиле, INP до 200 мс, CLS до 0,1. В CI гоняйте Lighthouse на ключевых шаблонах, в проде собирайте RUM через web-vitals и ловите регресс после релизов. У команды должен быть простой ритуал: любой новый виджет приносит цифры и план отката.