Core Web Vitals в 2026: что означают LCP, INP и CLS и как их улучшить

Сайт может загружаться достаточно быстро, но реагировать на нажатия с заметной задержкой. Другой сайт может моментально показать контент, но во время загрузки его блоки начинают прыгать по экрану.

Именно поэтому понятие «быстрый сайт» сложнее одной цифры.

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

В 2026 году основными Core Web Vitals остаются:

• LCP — Largest Contentful Paint;
• INP — Interaction to Next Paint;
• CLS — Cumulative Layout Shift.

Эти показатели полезны и для технического SEO, и для разработки, но их важно правильно интерпретировать.

Core Web Vitals — не оценка качества всего сайта и не формула продаж. Это три измеряемых сигнала о конкретных аспектах реального пользовательского опыта.

Что такое Core Web Vitals

Core Web Vitals — набор метрик, которые Google использует для оценки ключевых аспектов взаимодействия пользователя со страницей.

Каждая метрика отвечает за отдельную часть опыта:

• LCP — загрузку;
• INP — отзывчивость;
• CLS — визуальную стабильность.

Важно, что Core Web Vitals ориентированы не только на лабораторный тест.

Google может использовать данные реальных пользователей Chrome — так называемые field data.

Поэтому ситуация, когда локальный тест разработчика показывает отличный результат, а Search Console сообщает о проблеме, вполне возможна.

Какие значения Core Web Vitals считаются хорошими

Метрика Хорошо Нужно улучшить Плохо LCP до 2,5 с свыше 2,5 до 4 с свыше 4 с INP до 200 мс свыше 200 до 500 мс свыше 500 мс CLS до 0,1 свыше 0,1 до 0,25 свыше 0,25

При этом Google ориентируется не на лучший или худший единичный визит.

Для оценки используется 75-й перцентиль: примерно 75% измеренных посещений должны соответствовать рекомендованному значению или быть лучше него.

Мобильные и десктопные данные следует анализировать отдельно.

LCP: насколько быстро пользователь видит основной контент

Largest Contentful Paint измеряет время, необходимое для отображения крупнейшего релевантного элемента в видимой области страницы.

Им может быть:

• крупное изображение;
• hero-баннер;
• постер видео;
• большой текстовый блок;
• другой значимый элемент первого экрана.

LCP помогает ответить на практический вопрос: когда пользователь увидел основное содержимое страницы?

Хорошим ориентиром считается LCP до 2,5 секунды.

Что чаще всего ухудшает LCP

Слишком большое hero-изображение

Одна из наиболее распространенных причин — тяжелая фотография или баннер на первом экране.

Если браузеру необходимо загрузить несколько мегабайт до отображения основного визуального элемента, LCP закономерно ухудшается.

Медленный ответ сервера

Если HTML приходит с большой задержкой, браузер физически не может начать отображение основного контента раньше.

Причиной может быть хостинг, серверная логика, база данных, отсутствие кеширования или внешний API.

Ресурсы, блокирующие рендеринг

CSS, JavaScript и шрифты могут задерживать момент, когда браузер способен отрисовать страницу.

Не каждый такой файл является проблемой. Важно определить, что действительно требуется для первого экрана, а что может загрузиться позже.

Неправильный приоритет загрузки

Браузер иногда обнаруживает основной ресурс слишком поздно, особенно когда изображение появляется через сложный JavaScript или CSS.

Тогда даже хорошо оптимизированный файл начинает загружаться с задержкой.

Как улучшить LCP

В зависимости от причины могут помочь:

• уменьшение размера главного изображения;
• подходящий формат изображения;
• responsive images;
• улучшение серверного ответа;
• кеширование;
• сокращение render-blocking ресурсов;
• ранняя загрузка критичного LCP-ресурса;
• упрощение перегруженного первого экрана.

Оптимизировать необходимо реальную причину.

Если LCP-элементом является текстовый блок, бесконечное сжатие изображений проблему не решит.

INP: насколько быстро сайт реагирует на пользователя

Interaction to Next Paint оценивает отзывчивость интерфейса.

В расчет попадают такие взаимодействия, как:

• клик мышью;
• касание сенсорного экрана;
• взаимодействие с клавиатуры.

INP показывает задержку между действием пользователя и моментом, когда браузер может показать следующий визуальный результат.

Хорошим значением считается INP до 200 миллисекунд.

В 2024 году INP заменил предыдущую метрику FID в наборе Core Web Vitals.

Почему сайт может иметь плохой INP

Тяжелый JavaScript

Если главный поток браузера занят продолжительной JavaScript-задачей, пользователь может нажать кнопку, но интерфейс не сможет сразу отреагировать.

На мощном компьютере проблема иногда почти незаметна.

На менее производительном смартфоне тот же код может давать значительно большую задержку.

Сложные обработчики событий

Одно нажатие может запускать большой объем синхронной логики: вычисления, обновление DOM, фильтрацию большого массива данных или рендеринг множества компонентов.

Сторонние скрипты

Чаты, аналитика, рекламные платформы, A/B-тесты и другие сторонние сервисы тоже используют ресурсы браузера.

Один небольшой сервис может почти не влиять на страницу. Большое количество одновременно работающих интеграций — уже другая ситуация.

Избыточный ререндеринг

В сложных JavaScript-приложениях INP иногда ухудшается из-за лишних обновлений большого количества компонентов.

Проблема в такой ситуации заключается не в названии фреймворка, а в конкретной архитектуре и реализации.

Как улучшить INP

В зависимости от проблемы могут помочь:

• разбиение крупных JavaScript-задач;
• удаление ненужного кода;
• оптимизация обработчиков событий;
• сокращение дорогих DOM-операций;
• аудит сторонних скриптов;
• отложенная загрузка некритичной логики;
• оптимизация компонентов и ререндеринга;
• тестирование на реальных мобильных устройствах.

Важно не оценивать отзывчивость сайта исключительно по скорости первого открытия.

Страница может иметь хороший LCP и при этом плохой INP.

CLS: насколько стабилен макет

Cumulative Layout Shift оценивает неожиданные смещения видимых элементов страницы.

Классический пример: пользователь собирается нажать кнопку, но сверху появляется баннер, контент смещается — и нажатие попадает на другой элемент.

Или человек уже читает текст, а после загрузки веб-шрифта строки меняют размер и вся страница сдвигается.

Для CLS хорошим считается значение до 0,1.

В отличие от LCP и INP, CLS не измеряется в секундах или миллисекундах. Это безразмерная оценка визуального смещения.

Что чаще всего ухудшает CLS

Изображения без зарезервированного пространства

Если браузер заранее не знает размеры изображения, он может сначала показать текст, а после загрузки картинки сдвинуть контент вниз.

Реклама и динамические баннеры

Блок, который появляется после загрузки страницы без заранее выделенного пространства, способен сместить весь расположенный ниже контент.

Шрифты

Замена системного шрифта на веб-шрифт после его загрузки иногда изменяет ширину и высоту текста.

Это может привести к заметным смещениям.

Контент, добавляемый над видимой областью

Cookie-баннеры, уведомления и промо-блоки необходимо реализовывать так, чтобы они без необходимости не сдвигали уже отображаемый контент.

Как улучшить CLS

Типичные решения:

• задавать размеры или aspect ratio для изображений и видео;
• резервировать пространство под рекламу и виджеты;
• аккуратно настраивать загрузку шрифтов;
• не вставлять новый контент выше текущего без действия пользователя;
• проверять асинхронно загружаемые компоненты;
• тестировать страницу и после первоначальной загрузки.

Почему 75-й перцентиль важнее одного идеального теста

Core Web Vitals предназначены для оценки реального опыта широкой аудитории.

У посетителей разные:

• устройства;
• процессоры;
• сети;
• условия браузера;
• географическое положение;
• состояние кеша.

Поэтому результат одного запуска на мощном компьютере и быстром Wi-Fi не описывает опыт всей аудитории.

Google использует 75-й перцентиль, чтобы оценивать достаточно большую долю реальных посещений.

Например, LCP на уровне 2,3 секунды для 75-го перцентиля означает, что примерно 75% измеренных посещений имели результат 2,3 секунды или лучше.

Почему Search Console не становится зеленой сразу после исправления

Core Web Vitals в Search Console основаны на полевых данных реальных пользователей.

Они агрегируются за определенный период, поэтому техническое исправление сегодня не означает, что отчет полностью изменится завтра.

Новые посещения должны постепенно заменить старые данные в агрегированном периоде.

Поэтому для оперативной диагностики во время разработки используются лабораторные инструменты, а для оценки результата в реальной аудитории — field data.

Почему Search Console объединяет страницы в группы

Search Console может группировать URL с похожим пользовательским опытом.

Например, десятки карточек товаров используют один и тот же шаблон и имеют одинаковую проблему с LCP.

В таком случае не обязательно вручную исправлять каждую страницу.

Причина часто находится в общем шаблоне или компоненте.

Поэтому при анализе Core Web Vitals важно искать не только проблемный URL, но и системную причину.

Core Web Vitals и PageSpeed Insights — в чем разница

PageSpeed Insights — инструмент анализа.

Core Web Vitals — метрики.

PageSpeed Insights может показывать данные реальных пользователей, когда они доступны, а также лабораторный анализ Lighthouse.

Это две разные части отчета.

Лабораторный тест полезен для технической диагностики прямо сейчас.

Field data помогают понять, что испытывали реальные пользователи за более длительный период.

Core Web Vitals и SEO

Google рекомендует добиваться хороших Core Web Vitals и использует эти показатели в своих системах ранжирования.

Но их влияние важно не преувеличивать.

Хорошие LCP, INP и CLS не гарантируют первые позиции.

Страница прежде всего должна соответствовать поисковому намерению пользователя и давать полезный, релевантный ответ.

Поэтому удалять важный контент только ради нескольких технических пунктов не имеет смысла.

Правильнее сочетать хороший контент с хорошим пользовательским опытом.

Core Web Vitals и конверсия

Плохая производительность способна создавать дополнительные препятствия.

Если основной контент появляется долго, кнопки реагируют с задержкой или макет постоянно сдвигается, пользователю становится сложнее выполнить нужное действие.

Но универсальной формулы «одна секунда LCP равна определенному проценту продаж» не существует.

Реальный эффект зависит от аудитории, типа проекта, источника трафика, продукта, UX и других факторов.

Поэтому после оптимизации стоит анализировать и бизнес-метрики: заявки, покупки, заполнение форм и другие целевые действия.

Можно ли получить хорошие Core Web Vitals на WordPress или конструкторе

Да.

Технология сама по себе не определяет итоговый результат.

WordPress, Webflow, Wix, custom development и другие платформы могут демонстрировать как хорошие, так и плохие Core Web Vitals.

На производительность влияют:

• тема;
• плагины;
• контент;
• изображения;
• сторонние сервисы;
• анимации;
• хостинг;
• архитектура;
• качество реализации.

Индивидуальная разработка способна дать больше контроля, но плохо реализованный custom-сайт тоже может быть медленным.

Платформу лучше оценивать по реальным метрикам и ограничениям конкретного проекта.

Как правильно проверять Core Web Vitals

PageSpeed Insights

Позволяет увидеть field data, если данных достаточно, и получить лабораторную диагностику страницы.

Google Search Console

Полезна для мониторинга групп страниц и системных проблем Core Web Vitals.

Chrome DevTools и Lighthouse

Удобны для разработки и поиска конкретной технической причины.

Реальные устройства

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

Задержку кнопки или заметное смещение контента иногда гораздо проще почувствовать на обычном смартфоне, чем увидеть в таблице.

В каком порядке исправлять Core Web Vitals

1. Определить, какая конкретно метрика не проходит рекомендуемый порог.
2. Найти проблемные типы страниц.
3. Определить конкретный элемент или пользовательский сценарий.
4. Найти системную техническую причину.
5. Внести изменения.
6. Проверить результат лабораторно.
7. Убедиться, что функциональность не сломалась.
8. Дождаться обновления полевых данных.

Это эффективнее, чем хаотично устанавливать очередной плагин для ускорения после каждого красного предупреждения.

Когда Core Web Vitals действительно требуют внимания

Оптимизация имеет высокий приоритет, если:

• важные группы страниц стабильно находятся в красной зоне;
• проблема особенно выражена на mobile;
• пользователи заметно ждут основной контент;
• интерфейс зависает во время ключевых действий;
• смещения макета мешают взаимодействию;
• проблема повторяется во всем шаблоне;
• ухудшение появилось после нового скрипта, плагина или редизайна.

Если все показатели уже находятся в хорошем диапазоне, большой бюджет на улучшение LCP с 2,1 до 1,9 секунды может быть менее полезен, чем исправление слабого контента или неудобной формы заявки.

Подход TimeKairos

В TimeKairos мы рассматриваем Core Web Vitals как часть технического качества сайта, а не как три магические цифры, напрямую определяющие продажи.

Сначала необходимо понять, какая метрика создает проблему и для каких пользователей.

Затем найти первопричину: изображение, сервер, JavaScript, сторонний сервис, шрифт, компонент или архитектуру страницы.

И только после этого оптимизировать.

Такой подход позволяет не тратить время на случайные изменения и не жертвовать важной функциональностью ради красивого технического отчета.

Вывод

Core Web Vitals в 2026 году — это LCP, INP и CLS.

LCP показывает, насколько быстро пользователь видит основной контент. INP — насколько быстро интерфейс реагирует на действие. CLS — насколько стабильной остается страница.

Хорошие ориентиры: LCP до 2,5 секунды, INP до 200 миллисекунд и CLS до 0,1.

Но сами цифры не должны становиться конечной целью.

Core Web Vitals полезны тогда, когда помогают обнаружить реальную проблему пользователя, а не когда сайт оптимизируется исключительно ради зеленого отчета.