Core Web Vitals на практике: как диагностировать LCP, INP и CLS и что чинить первым
1. За что отвечает каждая метрика: сначала разберитесь, потом правьте
Многие команды сразу запускают Lighthouse, видят кучу красных крестиков и начинают чинить всё подряд. Сначала поймите, что измеряет каждая метрика, — тогда и правки будут по делу.
| Показатель | Что измеряет | Критерий | Частые причины |
|---|---|---|---|
| LCP, отрисовка самого крупного элемента | Время загрузки самого крупного элемента первого экрана | ≤ 2,5 с | Слишком большая картинка на первом экране, блокирующие шрифты, медленный ответ сервера |
| INP: от взаимодействия до следующей отрисовки | Задержка отклика интерфейса после клика пользователя | ≤ 200 мс | Долгие задачи в главном потоке, слишком большой JS, сторонние скрипты |
| CLS: совокупный сдвиг макета | Насколько элементы смещаются во время загрузки страницы | ≤ 0,1 | У картинок нет размеров, под рекламу не зарезервировано место, подмена шрифта |
Считать нужно по 75-му процентилю: из 100 посетителей порог должны пройти первые 75. Среднее и медиана ничего не показывают. Данные CrUX смотрите в отчёте «Опыт» в Search Console — это те же данные, что Google использует как сигнал ранжирования.
Учитывайте и то, что метрики тянут друг друга: сжатие картинок снижает LCP, но при неверной стратегии lazy load LCP-элемент отложится до второго кадра; preload шрифтов снижает LCP, но слишком много preload съедает сетевые запросы и бьёт по INP. После каждой правки ждите 14 дней и смотрите данные реальных пользователей — не меняйте всё подряд.
2. Чиним LCP: начинаем с того, что даёт больше всего
LCP обычно даёт больше 50% всей выгоды от оптимизации трёх метрик. Он состоит из четырёх этапов — сначала посмотрите, на каком застряли вы.
| Этап LCP | Инструмент диагностики | Частые узкие места | Что делать |
|---|---|---|---|
| TTFB: ответ сервера | Waterfall в WebPageTest | Медленный рендеринг PHP, нет CDN | Кэш на периферии CDN, обновление PHP |
| Загрузка ресурсов | Производительность в Chrome DevTools | Картинка первого экрана не сжата, нет preload | WebP/AVIF, preload ключевой картинки |
| Отрисовка ресурсов | Возможности в Lighthouse | Шрифты блокируют рендеринг | font-display: swap + preload |
| Рендеринг на клиенте | Панель Performance с трейсом | SPA рендерится только после загрузки JS | SSR или скелетон |
Пример из практики: на главной странице B2B-промсайта несжатое изображение товара весит 1,8 МБ. TTFB в норме, а LCP застрял на 4,2 секунды. Переводим картинку в WebP, сжимаем до 320 КБ и добавляем fetchpriority=”high” — через неделю LCP падает до 1,9 секунды. Изменение затронуло только тег img, настройки сервера не трогали.
Выбор CDN-узлов и стратегия кэширования напрямую влияют на TTFB, см.Глобальное ускорение через CDN. Для многоязычных сайтов локализацию изображений стоит продумывать вместе с Работа с графиками на многоязычном сайте.
3. Исправление INP: самое трудоёмкое, но пропустить его нельзя
INP — новый показатель, заменивший FID в марте 2024 года. Он измеряет полную задержку от действия пользователя до реального отклика интерфейса. Чинить его сложнее, чем LCP, потому что проблемы разбросаны по всему JS-бандлу.
| Вопрос | Как диагностировать | Что делать | Ожидаемый эффект |
|---|---|---|---|
| Долгие задачи в главном потоке > 50 мс | Метки долгих задач на панели Performance | Разделение кода, Web Worker | INP снижается на 100–200 мс |
| Блокирующие сторонние скрипты | Панель Coverage показывает долю | Отложенная загрузка, async/defer | INP снижается на 50–150 мс |
| Слишком тяжёлые обработчики событий | Стек вызовов показывает затратные функции | Debounce и throttle, разделение обработчиков | INP снижается на 30–80 мс |
| Ресурсы, блокирующие рендеринг | Lighthouse: неиспользованные CSS/JS | Критический CSS инлайном, некритический — отложенно | INP снижается на 50–100 мс |
Контринтуитивный момент: плохой INP не всегда вина вашего кода. На B2B-сайтах часто стоят пиксель LinkedIn, плагин форм HubSpot и скрипт онлайн-чата — вместе они блокируют главный поток больше чем на 300 мс. Сначала разберите сторонние скрипты по приоритету загрузки — это даст результат быстрее, чем правки бизнес-логики.
4. Исправление CLS: быстрые победы со стабильным результатом
CLS — самый простой из трёх показателей: 90% проблем с CLS вызваны двумя причинами — у изображений не заданы размеры, а реклама или встроенный контент не имеют зарезервированного места.
| Виновник CLS | Как проверить | Что делать |
|---|---|---|
| У изображений не заданы width/height | Смотрим сдвиги в DevTools | Добавить тегу img width/height + aspect-ratio |
| Скачок при смене шрифта | Эффект FOIT/FOUT | font-display: swap + size-adjust |
| Реклама или вставки без зарезервированного места | Реклама загружается и сдвигает контент | Зарезервировать контейнер фиксированной высоты |
| Динамически вставляемый баннер | Всплывающая полоса уведомления сверху | Зарезервировать место, не сдвигать контент |
Пример из практики 2: у блога зарубежного SaaS-сайта CLS держался на 0,35. Причина — баннер «Подпишитесь на рассылку» вверху статьи вставлялся после загрузки JS и сдвигал весь текст вниз на 120 пикселей. Перевели баннер на серверный рендеринг и зарезервировали 120 px — через неделю CLS упал до 0,04.
5. Инструменты диагностики и порядок проверки
| Этап | Инструмент | Источник данных | Срок проверки |
|---|---|---|---|
| Найти проблему | Отчёт CrUX / отчёт об опыте в GSC | Данные реальных пользователей за 28 дней | Смотреть раз в неделю |
| Воспроизвести в лаборатории | Lighthouse / WebPageTest | Эмуляция Moto G4 на медленном 4G | Запустить до исправлений |
| Мониторинг в продакшене | CrUX / инструменты RUM | Тренды показателей по 75-му процентилю | Через 14 дней после запуска |
| Приёмка | Отчёт о ключевых веб-показателях в GSC | Все три показателя «пройдены» | Через 28 дней после запуска |
Типичная ошибка — смотреть только на локальную оценку Lighthouse. Lighthouse работает в чистой среде: без сети ваших реальных пользователей, без сторонних скриптов, без авторизации. Сайтов, где локально 95 баллов, а CrUX не проходит, очень много. После исправления обязательно дождитесь обновления скользящих данных за 28 дней — не объявляйте об успехе на третий день после релиза.
Оптимизация производительности и система метрик Core Web Vitals— это непрерывная работа, а не разовый проект.графиком обслуживания сайта Стоит закрепить ежемесячный отчёт по CWV как обязательный пункт.
Шесть. Как встроить бюджет производительности в процесс итераций
Один раунд исправлений CWV — не гарантия навсегда. Новые функции, новые плагины, новые маркетинговые скрипты снова ухудшают метрики. Правильный подход — вписать бюджет производительности в процесс релиза и проверять его перед каждым запуском.
| Тип страницы | Бюджет LCP | Бюджет INP | Бюджет CLS | Бюджет общего пакета JS |
|---|---|---|---|---|
| Главная и посадочные страницы | ≤ 2,0 секунды | ≤ 150 миллисекунд | ≤ 0,05 | ≤ 250KB gzip |
| Страница товара | ≤ 2,5 с | ≤ 200 мс | ≤ 0,1 | ≤ 350KB gzip |
| Страница блога | ≤ 2,5 с | ≤ 200 мс | ≤ 0,1 | ≤ 300KB gzip |
| Страницы контактов и форм | ≤ 2,0 секунды | ≤ 150 миллисекунд | ≤ 0,05 | ≤ 200KB gzip |
Перед каждым релизом прогоняйте эти типы ключевых страниц через Lighthouse CI в предпродуктивной среде: превышение бюджета — блокировка мержа. Для попапов, скриптов поддержки и пикселей, которые маркетинг добавляет на ходу, нужен чек-лист проверки: можно ли отложить загрузку скрипта, можно ли вынести его за пределы первого экрана, можно ли грузить его только на определённых страницах. Раз в три месяца делайте отчёт по CrUX и смотрите тренд 75-го процентиля: если какая-то категория страниц падает два месяца подряд — заводите проект на исправление.
Есть ещё один пункт, который часто упускают: управление изображениями. Если в новую статью блога загрузить несжатый оригинал, LCP сразу просядет. Подключите в бэкенде контента конвейер сжатия изображений по умолчанию: при загрузке автоматически конвертировать в WebP, сжимать до разумного размера и генерировать srcset — это гораздо проще, чем потом править каждую статью вручную. Этот конвейер согласуется с процессом управления медиаактивами, см.Управление медиаактивами.
Сторонние скрипты — главная причина ухудшения INP. Пиксели, чат-плагины и встроенные формы, которые маркетинг добавляет под новую кампанию, часто грузятся без задержки и все лезут на этап рендеринга первого экрана. Раз в квартал выгружайте список всех сторонних скриптов на сайте и проходите по нему: какие ещё нужны, какие можно отложить за первый экран, какие уже никто не смотрит и можно просто удалить. Сделайте эту проверку частью процесса релиза — это куда спокойнее, чем каждый раз оптимизировать постфактум.
И последнее — про критерии проверки: после исправления не смотрите только на локальную оценку Lighthouse, дождитесь обновления скользящих данных CrUX по реальным пользователям за двадцать восемь дней. Локальный прогон годится только для поиска проблем, но не для объявления успеха. Отправляйте ежемесячный отчёт по CWV руководителям разработки и маркетинга, чтобы производительность стала общим показателем для нескольких команд, а не KPI одного SEO-специалиста.
FAQ: частые вопросы
Что исправлять первым: LCP, INP или CLS?
Почему в Lighthouse 95 баллов, а Search Console всё равно показывает неудовлетворительный результат?
Сколько времени займёт снизить INP с 500 миллисекунд до 200?
Какой CLS считается нормальным?
Влияют ли Core Web Vitals напрямую на ранжирование?
Нужно ли смотреть CWV для мобильных и десктопа отдельно?
В заключение
Core Web Vitals — самая понятная по отдаче вложения часть технического SEO: у каждого показателя есть чёткий порог, чёткий инструмент диагностики и чёткий способ исправления. Не дайте сбить себя с толку оценке Lighthouse — смотрите реальные данные пользователей CrUX.
Три шага к результату: на этой неделе по отчёту «Опыт» в GSC определите худший показатель; на следующей исправьте первый в порядке LCP → CLS → INP; через 28 дней после запуска проверьте, все ли показатели в CrUX в норме. Если все три в пределах нормы, вы уже обошли 70% B2B-сайтов, выходящих на зарубежные рынки.
Фраза, которую стоит запомнить: CWV — это не игра в оценки, а реальное время ожидания пользователей. LCP — про картинку, INP — про отклик на действие, CLS — про то, что видят глаза. Всё хорошо только тогда, когда комфортно по всем трём.