Core Web Vitals в 2026: объяснение пороговых значений LCP, INP и CLS
Core Web Vitals остаются подтвержденным фактором ранжирования Google в 2026 году. В этом руководстве рассматриваются точные пороговые значения LCP, INP и CLS, причины сбоев и самые быстрые способы достижения «хороших»…
Core Web Vitals – это три метрики Google, оценивающие пользовательский опыт и используемые в качестве сигнала ранжирования. В 2026 году эти метрики включают LCP (Largest Contentful Paint – отрисовка самого крупного контента), INP (Interaction to Next Paint – время отклика на взаимодействие) и CLS (Cumulative Layout Shift – совокупное смещение макета). Достижение «хорошего» порогового значения по всем трем параметрам напрямую влияет на улучшение видимости в поиске и снижение показателей отказов.
Что такое Core Web Vitals?#
Core Web Vitals – это подмножество сигналов Google, оценивающих удобство страницы для пользователя. Каждая метрика количественно определяет отдельную составляющую того, как реальные пользователи воспринимают страницу: скорость загрузки, скорость отклика на взаимодействие и визуальную стабильность. Google измеряет их с использованием данных, полученных от пользователей Chrome, и отображает результаты в Search Console, PageSpeed Insights и Chrome UX Report (CrUX).
Каково пороговое значение LCP в 2026 году?#
LCP измеряет время, необходимое для отрисовки самого крупного видимого элемента контента – обычно это главное изображение, большой текстовый блок или видеопостер – на экране. Пороговые значения следующие:
- Хорошо: ≤ 2,5 секунды
- Требуется улучшение: 2,5–4,0 секунды
- Плохо: > 4,0 секунды
Эти пороговые значения не изменились с тех пор, как LCP вошла в Core Web Vitals, и Google не сигнализировал о каких-либо изменениях на 2026 год. Планка в 2,5 секунды установлена намеренно высокой: она стимулирует сайты использовать оптимизированные изображения, применять быструю CDN и исключать ресурсы, блокирующие отрисовку.
Что вызывает медленный LCP?
Наиболее распространенные причины низкой скорости LCP:
- Неоптимизированные главные изображения – большие PNG или JPEG, передаваемые без использования современных форматов, таких как WebP или AVIF.
- Ресурсы, блокирующие отрисовку – синхронные скрипты или CSS, которые задерживают первую отрисовку браузера.
- Медленный ответ сервера (TTFB) – время до первого байта выше ~600 мс напрямую влияет на время LCP.
- Ленивая загрузка элемента LCP –
loading="lazy"на главном изображении откладывает загрузку самого важного ресурса. - Отсутствие указания предварительной загрузки – неиспользование
<link rel="preload">для изображения LCP.
Как исправить LCP
- Определите элемент LCP с помощью PageSpeed Insights или раздела Chrome DevTools "Largest Contentful Paint".
- Преобразуйте изображение в WebP или AVIF и предоставьте его в правильном размере отображения.
- Добавьте
<link rel="preload" as="image">для изображения LCP в<head>. - Перейдите к хосту или CDN с TTFB менее 200 мс на 75-м процентиле.
- Удалите или отложите любые скрипты, блокирующие отрисовку в верхней части страницы.
Каково пороговое значение INP в 2026 году?#
INP заменил First Input Delay (FID) в качестве Core Web Vital в марте 2024 года и остается метрикой интерактивности в 2026 году. INP измеряет задержку всех взаимодействий с пользователем – кликов, нажатий и событий клавиатуры – в течение всего жизненного цикла страницы, а затем сообщает наихудшее значение на 98-м процентиле.
- Хорошо: ≤ 200 миллисекунд
- Требуется улучшение: 201–500 мс
- Плохо: > 500 миллисекунд
В отличие от FID, который измерял только первое взаимодействие, INP наказывает за любое медленное взаимодействие во время посещения. Это делает его гораздо более репрезентативным для реального раздражения пользователей.
Что вызывает высокий INP?
- Длительные задачи в основном потоке – JavaScript, который блокирует основной поток более чем на 50 мс, задерживает обработку ввода.
- Тяжелые обработчики событий – прослушиватели onClick или onChange, которые запускают ресурсоемкие обновления DOM.
- Сторонние скрипты – аналитика, чат-виджеты и рекламные скрипты, которые конкурируют за время основного потока.
- Стоимость гидратации в SPA – сайты React, Vue или Angular, которые повторно гидратируют большие деревья компонентов при загрузке.
Как исправить INP
- Откройте Chrome DevTools → панель Performance → запишите взаимодействие и определите длительные задачи.
- Разбейте длительные задачи на более мелкие части, используя
scheduler.yield()илиsetTimeout(..., 0)для передачи управления браузеру. - Проведите аудит сторонних скриптов с помощью панелей Coverage и Network; отложите или удалите некритические скрипты.
- Используйте
startTransition(React) или эквивалентные API фреймворка, чтобы снизить приоритет несрочных обновлений состояния. - Минимизируйте размер DOM – страницы с десятками тысяч узлов имеют более медленный пересчет стилей после каждого взаимодействия.
Каково пороговое значение CLS в 2026 году?#
CLS измеряет неожиданные визуальные сдвиги – элементы, перемещающиеся во время загрузки страницы. Он оценивается как безразмерный агрегат всех сдвигов макета, не вызванных вводом пользователя.
- Хорошо: ≤ 0,1
- Требуется улучшение: 0,1–0,25
- Плохо: > 0,25
CLS, равный 0,1, может показаться абстрактным, но на практике это означает, что совокупное воздействие сдвигов должно быть небольшим по отношению к области просмотра. Один большой баннер или изображение без указанных размеров может мгновенно перевести страницу в категорию "Плохо".
Что вызывает высокий CLS?
- Изображения без атрибутов
widthиheight– браузер не может зарезервировать место до загрузки изображения. - Динамически внедряемый контент – реклама, баннеры cookie или всплывающие окна с новостной рассылкой, которые сдвигают контент вниз.
- Веб-шрифты, вызывающие FOUT/FOIT – подмена шрифтов, которые изменяют длину строк и перекомпоновывают текстовые блоки.
- Поздняя загрузка встроенных элементов – iframe для YouTube или Twitter, у которых нет зарезервированного контейнера с пропорциями.
Как исправить CLS
- Всегда указывайте
widthиheightв тегах<img>или используйтеaspect-ratioв CSS. - Зарезервируйте место для рекламных блоков с помощью контейнера с min-height еще до загрузки рекламы.
- Используйте
font-display: optionalили предварительно загрузите важные веб-шрифты, чтобы предотвратить позднюю замену. - Оберните iframe в CSS-контейнер с пропорциями (
padding-topилиaspect-ratio: 16/9). - Избегайте вставки контента над существующим контентом после начальной загрузки.
Как измеряются Core Web Vitals?#
Google использует полевые данные (измерения реальных пользователей из CrUX) в качестве сигнала ранжирования, а не лабораторные данные. PageSpeed Insights показывает и то, и другое, но на ранжирование влияют только полевые данные. Страница должна пройти все три метрики на 75-м процентиле загрузок страницы, чтобы считаться «хорошей» для оценки удобства страницы.
Лабораторные инструменты – Lighthouse, WebPageTest – неоценимы для диагностики, но не могут заменить данные CrUX. Если в CrUX недостаточно трафика для URL, Google агрегирует данные на уровне источника.
Как отслеживать Core Web Vitals в масштабе#
Для сайтов с сотнями или тысячами страниц ручная проверка нецелесообразна. Правильный подход:
- Search Console → отчет Core Web Vitals – сгруппированное представление URL-адресов со статусами «Хорошо» / «Требует улучшения» / «Плохо» по метрикам.
- CrUX API или BigQuery – программное извлечение необработанных полевых данных для пользовательских панелей мониторинга.
- Real User Monitoring (RUM) – библиотеки, такие как
web-vitals.js, отправляют LCP, INP и CLS из реальных сеансов в вашу аналитику. - Автоматизированные аудиты – такие инструменты, как SeoChatAI, могут выявлять проблемы с Core Web Vitals вместе с техническим SEO, доступностью и аудитом готовности к ИИ за один проход.
Гарантирует ли прохождение Core Web Vitals улучшение рейтинга?#
Прохождение всех трех метрик с «хорошим» пороговым значением является необходимым, но недостаточным условием для достижения высоких позиций в рейтинге. Core Web Vitals – это сигнал, определяющий победителя в случае равенства других факторов: когда качество контента, релевантность и авторитетность равны, страница с лучшими показателями пользовательского опыта будет ранжироваться выше. Google никогда не раскрывал точный вес, но сигнал реален и задокументирован в их документации по системам ранжирования.
Практический вывод: исправьте Core Web Vitals, чтобы устранить нижний предел ранжирования, а затем сосредоточьтесь на контенте и авторитетности, чтобы прорваться через него.
Core Web Vitals и поиск с использованием ИИ в 2026 году#
Поскольку сгенерированные ИИ обзоры (ранее SGE) теперь появляются в результатах поиска Google, сигналы, оценивающие удобство страницы для пользователя, влияют на то, будет ли страница указана в качестве источника. Страницы, которые загружаются медленно, визуально нестабильны или не реагируют на действия, с меньшей вероятностью будут показаны. Запуск полного аудита сайта через SeoChatAI дает вам сводное представление о ваших оценках CWV, готовности структурированных данных и соответствии критериям цитирования ИИ, что становится все более актуальным, поскольку поисковые системы, отвечающие на вопросы с помощью ИИ, вытесняют традиционные клики по синим ссылкам.
Краткий справочник: пороговые значения Core Web Vitals в 2026 году#
| Метрика | Хорошо | Требует улучшения | Плохо |
|---|---|---|---|
| LCP | ≤ 2,5 с | 2,5 с – 4,0 с | > 4,0 с |
| INP | ≤ 200 мс | 201 мс – 500 мс | > 500 мс |
| CLS | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Все пороговые значения применяются на 75-м процентиле полевых данных. Одна страница с небольшим количеством очень медленных загрузок может перевести агрегированный показатель в категорию «Плохо», поэтому мониторинг на уровне процентилей важнее, чем медианные значения.
