Core Web Vitals — три полевые метрики пользовательского опыта: LCP оценивает появление крупнейшего контентного элемента, INP — отзывчивость после взаимодействий, CLS — визуальную стабильность. Ориентиры «хорошо» на 75-м перцентиле посещений: LCP не более 2,5 секунды, INP не более 200 мс, CLS не более 0,1. Начинать нужно с реальных данных пользователей и проблемных шаблонов, а Lighthouse использовать для диагностики, а не как единственную оценку.
Что обновлено 25.08.2026 для «Core Web Vitals: как измерить и улучшить LCP, INP и CLS»: удалён массовый универсальный хвост; добавлены состояния проверки, pre-release и post-release контроль; уточнены ограничения и действия после проверки.
Метрики и правильное чтение данных
Следующий связанный шаг: Мобильная версия сайта для SEO: как адаптировать и проверить. Для материала «Core Web Vitals: как измерить и улучшить LCP, INP и CLS» эта ссылка продолжает соседнюю задачу без повторения текущего раздела.
LCP: скорость появления главного содержимого
Largest Contentful Paint фиксирует время от начала навигации до отрисовки крупнейшего видимого изображения, текстового блока или другого поддерживаемого элемента. На карточке товара это часто основное фото, на лендинге — hero-изображение или крупный заголовок.
Плохой LCP раскладывают на этапы: время ответа сервера, задержку обнаружения ресурса, загрузку файла и задержку рендера. Без такого разложения команда может сжимать картинку, хотя основная потеря происходит до получения HTML.
INP: отзывчивость интерфейса
Interaction to Next Paint оценивает задержки взаимодействий на протяжении визита: клик, касание, ввод с клавиатуры. Время включает обработку события, ожидание главного потока и следующую отрисовку.
Плохой INP часто создают длинные задачи JavaScript, тяжелые обработчики, большие обновления DOM и сторонние виджеты. Ускорение первой загрузки не гарантирует быстрый отклик после нажатия фильтра или открытия меню.
CLS: визуальная стабильность
Cumulative Layout Shift суммирует неожиданные смещения элементов в течение жизни страницы. Пользователь воспринимает проблему, когда текст, кнопка или товар уезжают после загрузки шрифта, рекламы, изображения или динамического блока.
Смещения после ожидаемого пользовательского действия могут оцениваться иначе, но это не оправдывает неудобный интерфейс. Для SEO и UX важно устранить внезапные перестроения, из-за которых человек нажимает не туда.
Почему нужен 75-й перцентиль
Оценка по перцентилю показывает опыт большинства, не усредняя быстрые и очень медленные визиты в одно число. Метрики рассматривают отдельно для мобильных и десктопных посещений; мобильная сеть и устройство обычно создают более жесткие условия.
Среднее значение может скрыть значительную группу проблемных пользователей. Для собственной RUM-системы храните распределение, тип устройства, соединение, шаблон страницы и версию релиза.
Полевые и лабораторные данные
Полевые данные собираются у реальных посетителей и отражают устройства, сети, кэш, географию и поведение. CrUX и отчет Search Console агрегируют историю; изменения не появляются там мгновенно.
Лабораторные тесты Lighthouse и DevTools воспроизводимы и показывают причины, но запускаются в моделируемых условиях. Если лаборатория зеленая, а поле красное, ищите медленные сегменты, взаимодействия после загрузки, персонализацию и сторонние скрипты.
Диагностика LCP, INP и CLS
Следующий связанный шаг: Индексация сайта: как проверить и исправить исключенные страницы. Для материала «Core Web Vitals: как измерить и улучшить LCP, INP и CLS» эта ссылка продолжает соседнюю задачу без повторения текущего раздела.
Рабочий маршрут измерения
Начните с отчета Core Web Vitals в Search Console, чтобы найти группы URL. Затем откройте типовой URL в PageSpeed Insights и сравните данные конкретной страницы с данными источника. После этого воспроизведите проблему в DevTools и Performance.
Не тестируйте только главную. Выберите по одному URL каждого шаблона: категория, карточка, статья, форма, лендинг. Один шаблон может проходить, а другой — проваливать все три метрики.
Как разложить плохой LCP
Определите сам LCP-элемент в диагностике. Проверьте TTFB, редиректы, наличие ресурса в исходном HTML, приоритет запроса, размер и формат файла, CSS, который задерживает рендер, и момент вставки элемента JavaScript.
Hero-изображение обычно не следует лениво загружать. Оно должно быть обнаружимо из HTML; при необходимости используют приоритизацию и preload, но только для действительно критического ресурса. Массовый preload конкурирует за сеть и может ухудшить результат.
Как найти причину плохого INP
Запишите Performance trace во время реального медленного действия: открыть меню, применить фильтр, добавить товар. Найдите длинную задачу и разложите ее на обработчик события, выполнение стороннего кода, перерасчет стилей, layout и paint.
Разбивайте длинную работу, откладывайте некритические задачи, уменьшайте объем DOM и обновляйте только изменившуюся часть интерфейса. Сторонний чат или аналитика должны оцениваться по фактическому времени главного потока, а не по названию поставщика.
Как найти источник CLS
В DevTools включите отображение layout shifts и воспроизведите загрузку с очищенным кэшем. Проверьте изображения и iframe без размеров, баннеры, cookie-плашки, web fonts и контент, вставленный над уже видимой областью.
Резервируйте место через width/height или aspect-ratio, задавайте стабильные контейнеры для рекламы и не вставляйте уведомление над контентом. Для шрифтов выбирайте стратегию загрузки и близкую fallback-метрику, чтобы замена не перестраивала строки.
Почему оценка меняется между запусками
На результат влияют сеть, CPU, кэш, нагрузка сервера, рекламный аукцион и случайный сторонний код. Один запуск не доказывает улучшение. Сравнивайте медиану нескольких лабораторных прогонов при одинаковых условиях.
Полевую оценку сравнивают на достаточном периоде и по версиям релиза. Не приписывайте изменение единственной правке, если одновременно менялись контент, реклама и инфраструктура.
Оптимизация по приоритету
Сначала исправьте общие шаблонные причины
Если один компонент используется на тысячах страниц, его исправление даст больший эффект, чем ручная оптимизация отдельного URL. Сгруппируйте проблемы по шаблону и общему ресурсу: шапка, hero, карточка, фильтр, виджет.
Приоритет учитывает трафик, долю плохих посещений, бизнес-критичность и сложность. Страница оформления заказа с плохим INP может быть важнее информационной статьи с большим LCP.
Что делать с сервером и TTFB
Проверьте цепочку редиректов, кэш HTML, время приложения и базы, географию сервера, CDN и размер ответа. Медленный первый байт оставляет слишком мало бюджета для LCP, даже если изображение оптимизировано.
Отделяйте холодный старт, отсутствие кэша и стабильную задержку. Добавьте серверные тайминги и трассировку, чтобы не оптимизировать фронтенд вслепую.
Изображения, CSS и шрифты
Отдавайте изображение в размере, близком к отображаемому, используйте подходящий современный формат и responsive `srcset`. Некритические изображения загружайте лениво, а критические не прячьте за каруселью и скриптом.
Удаляйте неиспользуемый CSS осторожно, разделяйте критические и некритические стили, сокращайте блокирующие шрифты. После оптимизации проверьте визуальные регрессии и доступность, а не только число в отчете.
JavaScript и сторонние сервисы
Сократите объем кода на стартовом маршруте, удалите неиспользуемые библиотеки, применяйте code splitting и отложенную загрузку. Главный поток должен быстро освобождаться для действий пользователя.
Создайте реестр сторонних скриптов: владелец, цель, страницы, момент загрузки, вес и время CPU. Скрипт без владельца и измеримой пользы — кандидат на удаление, особенно если он работает на всех страницах.
Как принять исправление
До релиза зафиксируйте исходную точку, контрольные сценарии и бюджет производительности. В CI можно проверять размер бандла и лабораторные регрессии, но не превращайте один Lighthouse score в жесткую бизнес-истину.
После релиза подтвердите отсутствие ошибок, сравните RUM по версии и дождитесь обновления полевых агрегатов. Улучшение считается устойчивым, если оно воспроизводится и не ухудшает конверсию, функциональность или доступность.
План исправления Core Web Vitals за один цикл
Вместо задачи «сделать 100 баллов» выберите один проблемный шаблон и одну метрику. Цель — улучшить опыт реальных пользователей без функциональных регрессий.
Порядок действий
- В Search Console или RUM найдите шаблон с большим трафиком и плохой полевой оценкой.
- Выберите три–пять репрезентативных URL и сохраните полевые и лабораторные исходные значения.
- Определите элемент или взаимодействие: LCP-ресурс, медленный клик для INP либо источник сдвига CLS.
- Запишите trace и разложите задержку на сервер, сеть, выполнение JavaScript, style/layout и paint.
- Составьте короткий список гипотез с ожидаемым влиянием и риском; выберите одну общую причину шаблона.
- Внедрите изменение на тестовом окружении и повторите одинаковые сценарии несколькими прогонами.
- Проверьте функциональность, доступность, визуальную стабильность и отсутствие ошибок в браузерах.
- Выпустите изменение с версией, сравните RUM и отслеживайте полевые данные после накопления выборки.
Контрольный чек-лист
- Использованы реальные полевые данные
- Мобильные и десктопные данные разделены
- Проверены разные шаблоны
- LCP-элемент точно определен
- Для INP записано конкретное действие
- Источник CLS воспроизведен
- Сторонние скрипты учтены
- Есть исходную точку и версия релиза
- Проверена функциональность после оптимизации
- Результат подтвержден в поле
Таблица решений
| Плохая метрика | Типичная проверка | Первое практическое действие |
|---|---|---|
| LCP | TTFB и момент обнаружения LCP-ресурса | Убрать задержку сервера или сделать ресурс приоритетным |
| INP | Длинные задачи во время конкретного клика | Разбить работу и сократить обработчик |
| CLS | Элемент, вызвавший layout shift | Зарезервировать место и стабилизировать вставку |
| Поле хуже лаборатории | Сегменты устройств, маршруты, сторонний код | Подключить RUM и воспроизвести реальный сценарий |
| Один шаблон хуже остальных | Общие компоненты и ресурсы | Исправить шаблон, затем масштабировать |
Частые вопросы
Core Web Vitals напрямую влияют на позиции?
Они относятся к сигналам качества пользовательского опыта, но не заменяют релевантность и полезный контент. Идеальные метрики не гарантируют топ.
Почему PageSpeed Insights показывает две оценки?
Полевые данные отражают реальные визиты за период, лабораторные — один моделируемый запуск для диагностики.
Нужно ли стремиться к 100 баллам Lighthouse?
Нет. Цель — хорошие полевые метрики и удобный интерфейс; последние баллы могут стоить дорого и не улучшать опыт заметно.
Как быстро обновятся полевые данные?
Они агрегируются за период и меняются не сразу после релиза. Для быстрой проверки используйте RUM и лабораторные тесты.
Матрица диагностики LCP, INP и CLS
Для темы «Core Web Vitals: как измерить и улучшить LCP, INP и CLS» проверка строится по состояниям, а не по одному скриншоту или индикатору сервиса. В таблице нет универсальных проектных порогов: ожидаемое поведение задаётся спецификацией конкретного сайта и подтверждается на реальном URL.
| Состояние | Проверка | Нормальный результат | Типичная ошибка | Исправление |
|---|---|---|---|---|
| Плохой LCP | Полевые данные и разбивка элемента | Определён реальный LCP-элемент и его этап задержки | Оптимизируют все изображения сразу | Исправить конкретно TTFB, загрузку, декодирование или рендер |
| Плохой INP | Профилирование длинного взаимодействия | Найдена обработка, блокирующая основной поток | Удаляют скрипт без проверки события | Разбить работу, сократить обработчик, повторить сценарий |
| Плохой CLS | Запись сдвигов и DOM-источник | Найден элемент без зарезервированного места | Меняют шрифт, не проверив баннер | Задать размеры/контейнер и повторить загрузку |
| Лаборатория хорошая, поле плохое | Сегменты устройства, URL и периода | Различие объясняется реальными условиями | Считать один запуск истиной | Диагностировать медленные сегменты и шаблоны |
| Регрессия после релиза | Сравнение версий и компонентов | Причина связана с конкретным изменением | Ждать обновления поля без rollback | Откатить компонент либо выключить флаг |
| Сторонний сервис | Waterfall и long tasks | Подтверждён вклад конкретного скрипта | Удаляют без владельца бизнес-функции | Ограничить загрузку и согласовать компромисс |
Корректный и ошибочный сценарий
Корректно: команда называет проблемный шаблон, элемент или взаимодействие, исправляет причину и отдельно ждёт обновления полевых данных.
Ошибочно: цель формулируется как «получить 100 в Lighthouse», хотя пользовательский барьер и полевой сегмент не определены.
Контроль до релиза
- Зафиксировать полевые и лабораторные данные по типам страниц
- Определить владельца каждого компонента
- Подготовить feature flag или rollback для рискованного изменения
Контроль после релиза
- Повторить лабораторный сценарий на том же профиле
- Проверить отсутствие функциональной регрессии
- Назначить дату чтения обновлённых полевых данных
Критерии готовности: Core Web Vitals: как измерить и улучшить LCP, INP и CLS
- Каждое состояние проверено на целевом шаблоне и хотя бы одном граничном варианте. Для темы «Core Web Vitals: как измерить и улучшить LCP, INP и CLS» критерий проверяется в описанном контексте.
- Ожидаемый HTTP, HTML или интерфейсный результат зафиксирован до изменения. Для темы «Core Web Vitals: как измерить и улучшить LCP, INP и CLS» критерий проверяется в описанном контексте.
- Назначен владелец исправления и условие отката при регрессии. Для темы «Core Web Vitals: как измерить и улучшить LCP, INP и CLS» критерий проверяется в описанном контексте.
- После выпуска повторена та же проверка без кэша и привилегированного доступа. Для темы «Core Web Vitals: как измерить и улучшить LCP, INP и CLS» критерий проверяется в описанном контексте.
Работа по теме «Core Web Vitals: как измерить и улучшить LCP, INP и CLS» закрывается техническим доказательством, а не ожиданием будущего роста. Поисковый эффект оценивают позже и только по фактическим данным.
Получите бесплатный аудит и стратегию роста
Изучим сайт, покажем точки роста и подготовим прогноз до квалифицированных лидов и оборота из SEO/GEO.