⏱️Core Web Vitals в 2026: что осталось важным, а что уже нет

Core Web Vitals прошли полный цикл отраслевой моды: паника при анонсе, массовые доработки ради зелёной зоны, разочарование от того, что позиции не выросли, и наконец — спокойное отношение как к одному из многих факторов.

Два года назад я писал про переход с FID на INP. С тех пор набор метрик не менялся, а вот понимание того, что с ними делать, устоялось. Ниже — что из практики оптимизации скорости сегодня реально окупается, а что осталось ритуалом.

Три метрики и пороги

Метрика	Что измеряет	Хорошо	Плохо
LCP (Largest Contentful Paint)	Когда отрисовался самый крупный элемент первого экрана	≤ 2,5 с	> 4,0 с
INP (Interaction to Next Paint)	Задержка отклика на действия пользователя за всю сессию	≤ 200 мс	> 500 мс
CLS (Cumulative Layout Shift)	Насколько содержимое «прыгает» при загрузке	≤ 0,1	> 0,25

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

Честно про вклад в ранжирование

Вклад есть, и он небольшой.

Google прямо говорит, что скорость — фактор, но фактор второстепенный по сравнению с релевантностью. Практическое правило, которое подтверждается наблюдениями: CWV работает как тайбрейкер. Между двумя одинаково релевантными страницами выше окажется быстрая. Медленная страница с уникальным нужным содержанием обгонит быструю пустышку всегда.

Яндекс отдельного аналога CWV не публикует, но скорость учитывает, и в Вебмастере есть свой раздел со скоростью загрузки.

Отсюда приоритет: если у страницы проблема с содержанием — заниматься содержанием. Оптимизация LCP с 3,1 до 2,4 секунды не вытащит страницу, которой нечего сказать. Обратное тоже верно: если содержание хорошее, а сайт грузится пять секунд — вы теряете и позиции, и людей, и это стоит починить.

Где CWV действительно решает

Ранжирование — не единственная и, честно говоря, не главная причина заниматься скоростью.

Отказы. Связь между временем загрузки и уходом с сайта прямая и заметная гораздо сильнее, чем связь с позициями. Пользователь, который ушёл через три секунды ожидания, — потерянная конверсия сегодня, а не гипотетическая позиция через месяц.

Мобильный трафик. Разрыв между десктопом и мобильными в CWV обычно огромный. Именно мобильная версия чаще всего и портит 75-й перцентиль.

Краулинговый бюджет. Медленный сервер = меньше страниц за визит робота. Для крупного сайта это прямое влияние на полноту индексации, и оно куда весомее, чем эффект CWV на ранжирование.

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

Чем мерить

Ключевое различие, из-за которого происходит половина недоразумений:

Лабораторные данные — синтетический замер в контролируемых условиях. Lighthouse, PageSpeed Insights (верхняя часть отчёта), WebPageTest. Воспроизводимы, годятся для отладки, не отражают реальность.

Полевые данные (RUM) — то, что реально испытали пользователи. CrUX (Chrome User Experience Report), поле в PageSpeed Insights, Search Console → «Основные интернет-показатели», собственный сбор через web-vitals. Именно они идут в оценку.

Классическая ситуация: в Lighthouse 98 баллов, в поле — «плохо». Причин обычно две: лаборатория меряет одну страницу, а поле — все; и лаборатория меряет на быстром канале, а поле включает мобильный интернет в электричке.

Вывод: оптимизировать по лабораторным, оценивать по полевым. Балл Lighthouse — инструмент отладки, а не цель.

Отдельно: INP невозможно нормально измерить лабораторно. Он про реальные взаимодействия реальных людей за всю сессию. Синтетический замер даёт в лучшем случае TBT как приблизительный ориентир.

Что даёт результат

LCP

• Найти сам элемент. В Lighthouse он подписан явно. В 90% случаев это либо главная картинка, либо заголовочный блок.
• fetchpriority="high" на LCP-картинку и никакого loading="lazy" на ней. Ленивая загрузка изображения первого экрана — самая частая и самая обидная ошибка: она делает ровно противоположное задуманному.
• Современные форматы — WebP, AVIF. Обычно это самая крупная разовая победа.
• Явные width и height — заодно закрывает CLS.
• preconnect к домену, откуда грузится LCP-ресурс, если он внешний.
• Время ответа сервера (TTFB). Если сервер думает 800 мс, никакая фронтенд-оптимизация LCP до 2,5 с не доведёт. Кэширование на стороне сервера здесь даёт больше, чем всё остальное вместе.

INP

• Разбить длинные задачи. Любая синхронная работа дольше 50 мс блокирует отклик. Помогает scheduler.yield() там, где он доступен, или разбиение через таймауты.
• Выкинуть лишние скрипты. Основной источник плохого INP на большинстве сайтов — сторонние теги: аналитика, виджеты чатов, пиксели, коллтрекинг. Инвентаризация «что из этого реально используется» обычно выявляет два-три давно ненужных.
• Грузить сторонние скрипты отложенно. defer, async, а виджеты — по первому взаимодействию.
• Дать мгновенную визуальную реакцию на клик, даже если обработка займёт время. INP меряет время до следующей отрисовки, а не до завершения логики.

CLS

• Резервировать место под всё, что грузится позже: картинки (width/height или aspect-ratio), рекламные блоки, встраиваемые виджеты, баннеры куки.
• font-display: swap плюс size-adjust в @font-face — чтобы подмена шрифта не сдвигала текст.
• Не вставлять элементы над уже отрисованным содержимым. Уведомление, появляющееся сверху страницы через две секунды, — гарантированный сдвиг.

CLS обычно самая дешёвая из трёх метрик: чинится вёрсткой за несколько часов и потом не деградирует.

Что перестало давать результат

Практики, которые всё ещё встречаются в чек-листах, но сегодня либо бесполезны, либо вредны.

Погоня за 100 баллами в Lighthouse. Разница между 85 и 100 баллами почти не отражается в полевых данных, а стоит непропорционально дорого. Порог, за которым дальнейшая оптимизация не окупается, — примерно «все три метрики в зелёной зоне на мобильных».

Склейка всех скриптов и стилей в один файл. Практика из эпохи HTTP/1.1. При HTTP/2 и HTTP/3 мультиплексирование делает много мелких файлов нормальным, а один огромный бандл вредит: он блокирует дольше и хуже кэшируется при частичных изменениях.

Инлайн всего критического CSS. Осмысленно для небольшого объёма. Инлайн 80 КБ стилей в каждую страницу раздувает HTML, ухудшает TTFB и убивает кэширование.

Доменное шардирование. Антипаттерн при HTTP/2: лишние соединения вместо мультиплексирования.

AMP. Google перестал требовать AMP для попадания в новостные блоки ещё несколько лет назад. Поддерживать параллельную версию сайта сегодня — чистые издержки.

Минификация HTML. Экономит проценты при включённом gzip/brotli, усложняет отладку. Сжатие на сервере даёт несопоставимо больше.

Оптимизация десктопной версии. Оценка идёт по мобильным. Десктоп почти всегда и так в зелёной зоне.

Порядок работы

1. Search Console → «Основные интернет-показатели», вкладка «Мобильные». Полевые данные, группировка по типам страниц — сразу видно, какой шаблон проблемный.
2. Взять худший шаблон, а не главную страницу. Главную обычно уже оптимизировали, а весь трафик идёт на карточки.
3. PageSpeed Insights по конкретному URL — посмотреть, какая из трёх метрик красная. Чинить одну, а не всё сразу.
4. Починить, выкатить, ждать. Полевые данные обновляются с задержкой — окно 28 дней означает, что эффект будет виден не раньше чем через неделю-две и полностью проявится через месяц.
5. Проверить, что не сломали остальное.

Ждать — обязательный шаг. Частая ошибка: выкатили правку, назавтра посмотрели в Search Console, не увидели изменений, откатили или начали делать что-то ещё.

Итог

Core Web Vitals в 2026-м — гигиена, а не рычаг. Быть в зелёной зоне стоит: это влияет на отказы, на индексацию и немного на ранжирование. Вкладывать в путь от 90 к 100 баллам столько же сил, сколько в содержание сайта, — не стоит.

Практический порог: все три метрики в зелёной зоне на мобильных по полевым данным. Достигли — переключайтесь на то, что приносит больше, то есть на содержание и на то, как оно структурировано.