Core Web Vitals — набор из трёх ключевых метрик скорости и стабильности страницы, которые Google использует как прямой фактор ранжирования с 2021 года. На 2026 год набор состоит из LCP (скорость отрисовки основного контента), INP (отзывчивость на действия пользователя) и CLS (стабильность вёрстки). Сайт с проблемными Core Web Vitals в 2026 году теряет позиции в коммерческой выдаче Google и просаживает поведенческие сигналы в Яндексе. Знание метрик, инструментов замера и методов улучшения — часть базовой работы по техническому SEO.
Что такое Core Web Vitals
Core Web Vitals (CWV) — набор метрик пользовательского опыта от Google, которые измеряют скорость загрузки, отзывчивость и визуальную стабильность веб-страницы. Инициатива запущена в мае 2020 года, в июне 2021 года Core Web Vitals стали явным фактором ранжирования в Google.
Core Web Vitals — это три числовых показателя, каждый из которых разделён на три зоны качества — «Хорошо», «Требуется улучшение», «Плохо». Сайт считается прошедшим CWV, если 75% просмотров страницы попадают в зону «Хорошо» по каждой из трёх метрик. Замеры берутся из реальных данных пользователей Chrome (Chrome UX Report), не из лабораторных тестов.
На 2026 год набор Core Web Vitals состоит из:
- LCP (Largest Contentful Paint) — скорость отрисовки основного видимого блока на странице
- INP (Interaction to Next Paint) — отзывчивость на действия пользователя
- CLS (Cumulative Layout Shift) — кумулятивный сдвиг макета при загрузке
До марта 2024 года вместо INP в наборе была метрика FID (First Input Delay). FID измеряла задержку первого взаимодействия, но не учитывала задержек всех последующих. INP — более точный показатель: учитывает все взаимодействия и берёт 98-й перцентиль, что лучше отражает реальный пользовательский опыт.
Core Web Vitals в 2026 году — условие, без которого конкурентное ранжирование в Google невозможно в Google. Сайты с проблемными метриками теряют позиции в коммерческой выдаче, даже при сильном контенте и ссылочной массе.
Метрики Core Web Vitals в 2026 году
LCP — Largest Contentful Paint
LCP измеряет время от начала загрузки страницы до отрисовки самого большого видимого блока в первом экране. Обычно это главное изображение карточки товара, баннер на главной, заголовок статьи с фоновым изображением.
Целевые значения:
- Хорошо: менее 2,5 секунды
- Требуется улучшение: 2,5–4,0 секунды
- Плохо: более 4,0 секунды
На что влияет LCP: время ответа сервера (TTFB), скорость загрузки изображений и шрифтов, наличие блокирующего JavaScript и CSS, размер критических ресурсов. LCP — самая часто проседающая метрика на коммерческих сайтах в 2026 году.
INP — Interaction to Next Paint
INP измеряет задержку между действием пользователя (клик, тап, нажатие клавиши) и визуальным откликом страницы. В отличие от FID, который измерял только первое взаимодействие, INP охватывает все взаимодействия за время визита и возвращает значение по 98-му перцентилю.
Целевые значения:
- Хорошо: менее 200 мс
- Требуется улучшение: 200–500 мс
- Плохо: более 500 мс
На что влияет INP: тяжёлый JavaScript на основном потоке, длинные задачи (long tasks) более 50 мс, синхронные обработчики событий, неоптимизированный код фильтров и форм. Проблемы с INP типичны для сайтов с тяжёлым фронтендом: каталоги с фильтрами, интерактивные калькуляторы, формы с валидацией в реальном времени.
CLS — Cumulative Layout Shift
CLS измеряет суммарный сдвиг макета страницы при загрузке. Каждое изменение положения элемента во время отрисовки добавляется к общему показателю CLS. Высокий CLS означает «прыгающий» интерфейс — пользователь хочет нажать на кнопку, но кнопка сдвигается из-за подгрузки рекламы или шрифта, и пользователь нажимает не туда.
Целевые значения:
- Хорошо: менее 0,1
- Требуется улучшение: 0,1–0,25
- Плохо: более 0,25
На что влияет CLS: изображения без указанных размеров, рекламные блоки с динамической высотой, шрифты без font-display: swap, динамически вставляемый контент без зарезервированного места. Последствия CLS — самые визуально заметные для пользователей.
Сопутствующие метрики
Помимо трёх Core Web Vitals в индустрии используется набор сопутствующих метрик, которые помогают понять корневые причины проблем.
| Метрика | Что измеряет | Целевое значение |
|---|---|---|
| FCP (First Contentful Paint) | Время до отрисовки первого контентного элемента | менее 1,8 с |
| TTFB (Time to First Byte) | Время ответа сервера до начала передачи данных | менее 600 мс |
| TBT (Total Blocking Time) | Суммарное время блокировки основного потока (используется в Lighthouse) | менее 200 мс |
| FID (First Input Delay) | Задержка первого взаимодействия (устаревшая, заменена на INP с марта 2024) | менее 100 мс (исторически) |
FCP и TTFB важны для диагностики LCP: если TTFB более 1 секунды, LCP неизбежно превысит 2,5 секунды. TBT — лабораторный аналог INP, удобен для оптимизации во время разработки. Все сопутствующие метрики не являются Core Web Vitals в 2026 году, но входят в общую картину скорости загрузки.
Как замерить Core Web Vitals
Инструменты замера Core Web Vitals делятся на две группы: Field Data (реальные данные пользователей) и Lab Data (лабораторные замеры).
Google Search Console — раздел Core Web Vitals. Главный инструмент для мониторинга. Показывает Field Data по всему сайту, разделённые на «Хорошо», «Требуется улучшение», «Плохо» для мобильных и десктопных URL. Данные обновляются раз в 28 дней. Этот источник — приоритетный, потому что именно его учитывает алгоритм ранжирования Google.
Google PageSpeed Insights. Сервис по адресу pagespeed.web.dev. Для одной страницы показывает оба типа данных: Field Data из Chrome UX Report (если есть) и Lab Data из встроенного Lighthouse. Удобен для аудита конкретной страницы, не для сайта целиком. На 2026 год — самый распространённый инструмент для проверки CWV.
Chrome DevTools — Lighthouse. Встроен в Chrome (F12 → вкладка Lighthouse). Лабораторные замеры с детальным разбором проблем и рекомендациями. Удобен во время разработки, потому что показывает результат сразу после изменений. Лабораторные значения часто отличаются от Field Data на 20–40%.
Chrome UX Report (CrUX). База данных Google с реальными метриками пользователей Chrome для всех публичных сайтов. Доступ через API, BigQuery, дашборд CrUX. Источник данных для PageSpeed Insights и Search Console. Самостоятельная работа с CrUX нужна редко: обычно достаточно агрегированных данных в Search Console.
Сторонние сервисы. GTmetrix, WebPageTest, SpeedCurve — глубокий лабораторный анализ с возможностью замера из разных географических точек, на разных устройствах, при разных скоростях соединения. Для регулярного мониторинга требуют платной подписки.
Яндекс.Метрика. Раздел «Тайминг загрузки страниц» показывает реальную скорость сайта у пользователей. Не заменяет Search Console для Google, но даёт картину со стороны Метрики, которую учитывает Яндекс через поведенческие сигналы.
Как улучшить Core Web Vitals
Оптимизация Core Web Vitals — комбинация фронтенд-приёмов и серверных настроек. Стандартный набор: lazy loading изображений, минификация JS и CSS, использование WebP/AVIF, preload критичных ресурсов, кэширование на стороне браузера и CDN.
Вопрос «как улучшить Core Web Vitals» решается по трём направлениям, каждое — для своей метрики.
Как улучшить LCP
LCP — самая часто проседающая метрика и самая сложная в оптимизации. Основные направления:
- Снижение TTFB. Серверное кэширование, переход на VPS вместо shared-хостинга, выбор хостинга рядом с целевой аудиторией. TTFB менее 600 мс — обязательное условие для приемлемого LCP.
- Оптимизация LCP-изображения. Перевод в WebP или AVIF, размер не более 200–400 КБ, точное соответствие отображаемому размеру (без масштабирования через CSS), атрибут
fetchpriority="high"для критичного изображения. - Preload критических ресурсов. Шрифты, главное изображение, критический CSS подгружаются через
<link rel="preload">. Браузер начинает их загрузку как можно раньше. - Inline критического CSS. Стили для первого экрана встроены в
<head>, чтобы браузер мог начать отрисовку без ожидания внешнего CSS. - Удаление блокирующего JavaScript. Все некритичные скрипты — через атрибуты
deferилиasync. Сторонние скрипты — через Google Tag Manager с условиями загрузки.
Как улучшить INP
INP проседает чаще всего на интерактивных страницах с тяжёлым JavaScript. Основные направления:
- Дробление длинных задач. Любая JS-задача длиннее 50 мс блокирует основной поток. Разбиение через
setTimeout,requestIdleCallback,scheduler.yield(новый API). - Очистка от неиспользуемого JS. Анализ через Coverage в Chrome DevTools, удаление мёртвого кода, tree-shaking при сборке.
- Code splitting. Для SPA-приложений — загрузка только JS, нужного на текущей странице. Динамические импорты через
import(). - Web Workers для тяжёлых вычислений. Парсинг больших данных, сложные расчёты — переносятся в Web Worker, который не блокирует основной поток UI.
- Дебаунсинг обработчиков событий. Обработчики на
input,scroll,resize— через debounce или throttle, не каждое событие пересчитывает интерфейс.
Как улучшить CLS
CLS — самая простая в оптимизации метрика. Основные направления:
- Явные размеры для всех изображений и видео. Атрибуты
widthиheightв HTML — браузер резервирует место до загрузки изображения. Альтернатива — CSSaspect-ratio. - Зарезервированное место для рекламных блоков. Минимальная высота для контейнеров рекламы через CSS, чтобы блок не «прыгал» при подгрузке.
- Свойство font-display: swap. Браузер сразу показывает текст системным шрифтом, потом заменяет на кастомный. Без свойства — пустое место до загрузки шрифта.
- Корректная анимация. Только через
transformиopacity, не через изменениеwidth,height,top,left(последние вызывают сдвиг макета). - Динамический контент только в ответ на действия пользователя. Подгрузка дополнительного контента после клика, не автоматически при скролле.
Особенности в Яндексе и Google
Core Web Vitals в Яндексе и Google работают по-разному:
| Параметр | Яндекс | |
|---|---|---|
| Статус метрик | Прямой фактор ранжирования с июня 2021 года | Не выделены как явный фактор; учитываются через поведенческие сигналы Метрики |
| Источник данных | Chrome UX Report (реальные пользователи Chrome) | Яндекс.Метрика (реальные пользователи всех браузеров) |
| Главный инструмент мониторинга | Google Search Console раздел Core Web Vitals | Яндекс.Метрика раздел «Тайминг загрузки страниц» |
| Вес в ранжировании | Прямой, особенно для мобильной выдачи | Косвенный, через отказы и время на сайте |
| Что считается «хорошо» | 75% страниц в зоне «Хорошо» по каждой метрике | Время загрузки менее 3 секунд, низкие отказы |
На 2026 год для проектов на два рынка (Россия, Беларусь с долей Яндекса 25%+) оптимизация Core Web Vitals полезна и в Google (через прямой фактор), и в Яндексе (через поведенческие). Сам сервис Яндекс.Метрики не учитывает CWV в чистом виде, но улучшение скорости снижает отказы, увеличивает время на сайте и глубину просмотра — все эти показатели Яндекс учитывает в ранжировании.
Типичные ошибки
| Ошибка | Последствие | Решение |
|---|---|---|
| Оптимизация только лабораторных метрик без учёта Field Data | Lighthouse показывает 95+, у реальных пользователей опыт остаётся плохим | Приоритет Field Data в Search Console; лабораторные замеры — только для разработки |
| Lazy loading на главном изображении LCP | LCP-изображение отрисовывается с задержкой, метрика растёт до 4+ секунд | Без lazy loading на главном изображении; fetchpriority="high" для критичного изображения |
| Игнорирование INP — оптимизация только LCP и CLS | INP остаётся в красной зоне, статус Core Web Vitals «Плохо» сохраняется | INP оптимизируется через работу с JavaScript: разбивка задач, удаление неиспользуемого кода, Web Workers |
| Замеры скорости только на быстром офисном интернете | Иллюзия хорошей скорости, реальная картина у пользователей хуже на 30–50% | Эмуляция Slow 4G и Mid-tier device в Chrome DevTools или WebPageTest |
| Изображения без указанных размеров на странице | Высокий CLS, прыгающий интерфейс, негативный пользовательский опыт | Обязательные атрибуты width и height на каждом <img> или CSS aspect-ratio |
| Использование TBT как замены INP | TBT — лабораторный показатель, INP — реальный; результаты не всегда совпадают | Мониторинг INP через Field Data в PageSpeed Insights и Search Console |
| Шрифты без font-display: swap | FOIT (Flash of Invisible Text), сдвиг макета при загрузке шрифта | Свойство font-display: swap в каждом @font-face; preload для критичных шрифтов |
Часто задаваемые вопросы
Сколько времени уходит на улучшение Core Web Vitals?
Базовые улучшения (оптимизация изображений, lazy loading, font-display) — 2–4 недели. Глубокая оптимизация (рефакторинг JS, critical CSS, переход на VPS, CDN) — от 1 до 3 месяцев. Эффект в Search Console появляется через 28 дней — это период расчёта Field Data.
Что важнее в 2026: LCP, INP или CLS?
LCP. На большинстве сайтов это самая часто проседающая метрика и самая сложная в оптимизации. INP решается через работу с JavaScript, CLS — через корректную вёрстку. LCP требует одновременной работы со скоростью сервера, изображениями, шрифтами.
Можно ли пройти Core Web Vitals без перехода на VPS?
На shared-хостинге сложно, но возможно для небольших сайтов с минимумом контента. Для коммерческих проектов с тяжёлыми страницами и трафиком от 5000 посетителей в месяц — переход на VPS или выделенный сервер обычно неизбежен.
Как часто Google обновляет данные Core Web Vitals в Search Console?
Раз в день, с расчётным окном в 28 дней. Это означает, что любое улучшение начинает отражаться через несколько дней после внедрения, но полная картина появляется только через 28 дней после стабилизации изменений.
Существуют ли Core Web Vitals для Яндекса?
Аналога с тем же названием нет. Яндекс измеряет скорость через Метрику (тайминг загрузки, отказы, время на странице). Косвенно работа над Core Web Vitals улучшает и показатели Яндекс.Метрики, потому что причины проблем (медленные изображения, тяжёлый JS) одни и те же в обеих системах.
Что делать, если Field Data в PageSpeed Insights недоступны?
Это нормально для новых сайтов или сайтов с малым трафиком. Chrome UX Report требует минимального количества посещений (десятки тысяч в месяц), чтобы агрегировать данные. До накопления — опираться на Lab Data из Lighthouse, понимая, что они оптимистичнее реальных показателей.
Сколько стоит оптимизация Core Web Vitals в РБ?
Базовая (изображения, lazy loading, кэширование, плагины оптимизации) — 1000–2000 BYN разово. Комплексная (плюс работа с JS, critical CSS, переход на VPS, CDN) — 3000–6000 BYN. Глубокая (рефакторинг архитектуры, серверный рендеринг, ручная оптимизация TTFB) — от 6000 BYN, обычно в составе абонементного SEO-обслуживания.
Влияет ли AI Overviews на требования к Core Web Vitals в 2026 году?
Влияет косвенно. Для попадания в AI Overviews сайт должен быть индексируемым и соответствовать базовым требованиям качества контента. Core Web Vitals — часть общей оценки качества. Прямого требования «попасть в Field Data Хорошо для AI Overviews» нет, но сайты с проблемными метриками реже отбираются как источники для нейроответов.
Существуют ли отдельные требования к Core Web Vitals для мобильных и десктопных версий?
Целевые значения одинаковы (LCP менее 2,5 с, INP менее 200 мс, CLS менее 0,1), но Search Console показывает данные отдельно. Поскольку Google использует mobile-first indexing, мобильные показатели приоритетнее. На практике мобильные CWV хуже десктопных из-за более медленных устройств и сетей.
Материал отражает состояние Core Web Vitals на начало 2026 года. Google регулярно обновляет состав метрик и пороговые значения — последние изменения отслеживаются через web.dev и официальный блог Google Search Central.
