Core Web Vitals в 2026: какие метрики влияют на позиции в Яндексе, а какие нет

Core Web Vitals в 2026 году продолжают продавать как способ подняться в Яндексе, хотя Яндекс эти метрики не считает и отчёта по ним не публикует. Набор придуман в Google и собирается по браузеру Chrome, а владелец сайта платит за «вывод в зелёную зону» и ждёт роста в поиске, который на эти цифры не смотрит.

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

Чей это набор метрик и где скорость смотрит сам Яндекс

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

Яндекс к набору отношения не имеет: в панели вебмастера нет ни раздела Core Web Vitals, ни отчёта по LCP, CLS и INP, ни порогов, ни оценок в терминах этой спецификации, и фактором ранжирования Яндекс их не объявлял. У него своя система из двух частей. Первая — раздел диагностики скорости сайта в Яндекс.Вебмастере: данные из браузеров реальных посетителей с разбивкой по устройствам, названия показателей собственные и к LCP с INP не сводятся. Вторая — отчёты времени загрузки в Яндекс.Метрике: время ответа сервера, отрисовки и готовности страницы с разбивкой по устройству, региону и странице входа. Сегментация и находит проблему: среднее по сайту терпимо, а по мобильным визитам картина другая.

Отсюда главное: «оптимизируем Core Web Vitals, чтобы вырасти в Яндексе» — подмена цели. Честная связь работает через людей: человек нажал на ваш результат, две-три секунды видел пустой экран и вернулся в выдачу открывать конкурента. Для поисковика это короткий визит с возвратом, и он отличает его от визита, где человек прокрутил страницу и позвонил. Накопится достаточно возвратов — страница просядет, без всякого LCP. Цепочку я разбирал в статье про то, как скорость загрузки влияет на ранжирование в Яндексе, а какие сигналы поведения различает Яндекс — в материале про глубокий скроллинг и быстрый уход.

Состав набора, пороги и то, что в него не входит

Метрик три, и каждая измеряет свой дефект интерфейса, а не «скорость» вообще. LCP — время отрисовки крупнейшего элемента первого экрана: обычно это главная картинка, фон блока или крупный заголовок. CLS — совокупный сдвиг макета, то есть насколько сильно содержимое прыгало при загрузке без действий пользователя. INP — отзывчивость: сколько проходит от нажатия до отрисовки ответа. В марте 2024 года INP заменил в наборе метрику FID, которая мерила задержку только первого взаимодействия и потому почти всегда выглядела хорошо.

Метрика	Что измеряет	Хорошо	Требует улучшения	Плохо
LCP	отрисовка крупнейшего элемента первого экрана	до 2,5 с	от 2,5 до 4 с	свыше 4 с
CLS	совокупный сдвиг макета при загрузке	до 0,1	от 0,1 до 0,25	свыше 0,25
INP	задержка отклика на действие пользователя	до 200 мс	от 200 до 500 мс	свыше 500 мс

Пороги не «на 2026 год»: они заданы спецификацией и по годам не переписываются, менялся состав набора, а не границы. Два свойства оценки важнее цифр. Результат считается по 75-му процентилю реальных визитов: «хорошо» получается, когда метрика уложилась в порог у трёх четвертей посетителей, а среднее не используют специально — оно прячет хвост медленных визитов. И мобильные визиты оцениваются отдельно от настольных: типичная картина малого бизнеса — зелёный настольный трафик и красный мобильный.

Теперь о том, что в набор не входит. Сводный балл от 0 до 100 в PageSpeed Insights — взвешенная сумма лабораторных показателей инструмента Lighthouse, часть которых к набору не относится; вес коэффициентов Google менял, и одна страница в разные годы получала разный балл без правок. Не входят и четыре диагностических показателя: TTFB — быстрота ответа сервера, FCP — первая отрисовка хоть чего-нибудь, TBT — время блокировки главного потока длинными задачами, Speed Index — скорость заполнения экрана. Они подсказывают, где искать причину, но метрику не заменяют.

Разница денежная: балл поднимается и косметикой — сжатием картинок в подвале, чисткой неиспользуемых стилей, переносом счётчика в конец кода — при неизменном LCP. И наоборот, страница с баллом около шестидесяти может иметь все три метрики в зелёной зоне. Про подмену метрики удобной цифрой я писал в разборе настоящей метрики скорости.

Лабораторный прогон и полевые данные: разница, которая всё решает

Измерения бывают двух видов, и их постоянно смешивают. Лабораторное — один запуск на эмулируемом устройстве с искусственными ограничениями сети и процессора: так работает Lighthouse во встроенных инструментах браузера. Полевое — метрики с реальных визитов за период, они и дают оценку по процентилю. Условие жёсткое: нужно достаточно посещений от пользователей Chrome с включённой передачей статистики. У сайта с несколькими десятками визитов в сутки их нет, и зелёный балл доказывает только то, что эмулятор доволен.

Признак	Лабораторный прогон	Полевые данные
Откуда берётся	запуск на эмуляторе устройства и сети	браузеры реальных посетителей за период
Что показывает	потенциал страницы и список проблем	что фактически получили люди
Есть ли INP	нет: нужны действия пользователя	да
Нужен ли трафик	нет, работает на новом сайте	да, без посещений данных не будет

Порядок отсюда такой: сначала полевые данные — есть ли проблема, потом лабораторный прогон — откуда она. Без полевых данных решают по замерам Яндекса и по собственному телефону. Почему «зелёный» сайт может стоять на месте — в материале про Core Web Vitals как скрытую причину отсутствия роста.

LCP: что задерживает отрисовку первого экрана

Причин пять, и почти всегда работают три-четыре одновременно.

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

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

Шрифты. Если текст крупнейшего элемента ждёт нестандартный шрифт, он не отрисуется, пока файл не приедет. Помогают три приёма: раздавать шрифты со своего домена, оставить только используемые толщины и наборы символов, разрешить браузеру сразу показать текст подстановочным шрифтом.

Тяжёлый слайдер или видеофон в шапке: крупнейший элемент оказывается внутри карусели, которая ждёт свой сценарий, стили и несколько картинок разом. Слайдер из пяти слайдов проигрывает одной статичной картинке, тем более что дальше первого листает меньшинство. На этом спотыкаются дорогие дизайнерские сайты — есть разбор, почему дизайнерский сайт не попадает в топ.

Медленный ответ сервера и отсутствие кэша: если страница собирается заново из базы при каждом визите, эта работа добавляется ко времени отрисовки.

CLS: почему макет дёргается и как это прекратить

Сдвиг макета — самая дешёвая в исправлении метрика и самая заметная. Причин четыре.

Картинки и встроенные блоки без заданных размеров: браузер не знает, сколько места занять, рисует текст, а потом раздвигает его под приехавшее изображение. Исправляется указанием ширины и высоты у каждой картинки и каждой вставки видео или карты. Размеры задают пропорции, а не фиксируют пиксели, адаптивности это не мешает.

Плашки и баннеры, вставляемые после загрузки: уведомление о файлах cookie, полоса акции, предложение подписки. Если блок вклинивается в поток и толкает содержимое вниз, сдвиг получает каждый визит. Решение — резервировать место заранее либо показывать блок наложением.

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

Виджеты чата, формы обратного звонка и блоки отзывов от сторонних сценариев: их размер и момент появления заранее неизвестны. Нужен контейнер фиксированной высоты, а плавающие кнопки — поверх содержимого.

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

INP: кто съедает отзывчивость страницы

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

Главный виновник — сторонние сценарии: счётчики аналитики, пиксели рекламных систем, виджеты чатов, карты, подключаемые целиком ради одного адреса, кнопки социальных сетей, сервисы отзывов. Каждый добавляет работу в главный поток браузера, и пока поток занят, на нажатие он не отвечает. На сайтах, которые я разбираю, такой набор накопился за годы, и половина уже никем не используется.

Второй — длинные задачи в собственном коде: один большой сценарий, выполняемый целиком при загрузке, блокирует поток на сотни миллисекунд. Третий — обработчики, делающие лишнюю работу на каждое событие: форма, пересчитывающая весь блок на каждый символ.

Рабочий порядок: собрать список сторонних подключений, выяснить по каждому, кто и зачем им пользуется, выключить неиспользуемое, остальное загружать отложенно и только там, где оно нужно. Чат уместен на странице услуги и бесполезен в архиве блога. Ниже три метрики сведены в таблицу.

Метрика	Что её портит чаще всего	Что делать в первую очередь
LCP	тяжёлая картинка первого экрана, устаревший формат	уменьшить до размера показа, пересохранить, отдавать разные размеры
CLS	картинки и вставки без указанных размеров	задать ширину и высоту изображениям, видео и картам
INP	сторонние счётчики, чаты, карты, пиксели	выключить неиспользуемое, остальное загружать отложенно
INP	длинные задачи и обработчики на каждое событие	разбить сценарий, отложить всё, что не нужно до первого действия

Что реально ускоряет сайт на WordPress

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

Кэширование страниц: готовый HTML отдаётся без обращения к базе и без запуска темы и плагинов. В каталоге wordpress.org есть бесплатные решения — WP Super Cache, W3 Total Cache, LiteSpeed Cache на подходящем сервере. Что ставить, зависит от хостинга: у части провайдеров кэш включается на уровне сервера, и плагин поверх него мешает. Оговорка из практики: полностраничный кэш ломает динамику — корзину, формы с защитой от повторной отправки. Такие фрагменты выводят из кэша поимённо.

Работа с изображениями: пересохранение библиотеки в современные форматы, разумный набор размеров, исключение первого экрана из ленивой загрузки. Плагины сжатия в каталоге есть, например EWWW Image Optimizer или Smush. Но если фотографию вставляют в оригинальном размере, сжатие лишь уменьшит ущерб.

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

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

Когда гонка за баллами бессмысленна

Четыре ситуации, в которых деньги тратятся впустую. Проверяйте их до того, как соглашаться на работы.

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

Сайт и так в пределах порогов. Если LCP укладывается в две с половиной секунды, CLS ниже 0,1, INP ниже 200 миллисекунд, дальнейшее ускорение — работа ради цифры: разница между 2,2 и 1,9 секунды человеком не замечается.

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

Борьба за последние баллы вместо исправления метрики. Вижу регулярно: LCP на мобильных около пяти секунд, а подрядчик неделю поднимает балл с 88 до 95, вычищая неиспользуемые стили. Балл вырос, посетитель по-прежнему смотрит на белый экран.

Порядок проверки: от замера до правок

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

Шаг первый. Откройте сайт на своём телефоне по мобильной сети, а не по домашнему вайфаю, и пройдите путь клиента до отправки формы.

Шаг второй. Посмотрите диагностику скорости в Яндекс.Вебмастере и отчёты времени загрузки в Метрике, обязательно с разбивкой по устройствам.

Шаг третий. Возьмите не главную, а три-пять страниц, которые приводят людей из поиска, и проверьте каждую в PageSpeed Insights. Главная у большинства сайтов не самая посещаемая, а оптимизируют именно её.

Шаг четвёртый. Есть полевые данные — решайте по ним; нет — по первым двум шагам, а лабораторный прогон используйте как подсказку, где искать.

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

Шаг шестой. Через две-три недели вернитесь в полевые данные и в Вебмастер: изменение там видно с задержкой. Заодно посмотрите отказы и возвраты в выдачу по правленым страницам — это и было целью.

Что проверить	Где смотреть	Что считать нормой
Первый экран на телефоне по мобильной сети	свой телефон, путь клиента до отправки формы	содержимое видно сразу, ничего не прыгает
Скорость по реальным посетителям	диагностика скорости в Яндекс.Вебмастере	мобильные показатели не хуже настольных в разы
Три метрики набора	PageSpeed Insights, полевые данные в верхней части	LCP до 2,5 с, CLS до 0,1, INP до 200 мс
Поведение после правок	отказы и возвраты в выдачу	доля коротких визитов снижается

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

Ошибки, из-за которых оптимизация скорости не даёт результата

Оптимизируют главную, а трафик идёт на страницы услуг и статьи: балл вырос, посетители не заметили, потому что заходят не туда. Сравнивают замеры в разных условиях: утренний прогон с компьютера и вечерний с ноутбука по мобильной сети — это не «стало хуже»; прогон повторяют несколько раз, беря медиану.

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

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

И последнее — забывают, зачем всё это. Скорость нужна не ради баллов, а чтобы человек дошёл до заявки. Если после ускорения не изменились ни отказы, ни возвраты в выдачу, ни число обращений, работа была технической, но не коммерческой. Поэтому SEO-продвижение сайта с технической доработкой я выстраиваю от поведения посетителей к правкам, а не от отчёта инструмента к галочкам.

Коротко

• Core Web Vitals — набор метрик Google. Яндекс их не считает, отчёта не публикует, фактором ранжирования не объявлял, раздела с ними в панели вебмастера нет.
• У Яндекса своя оценка: диагностика скорости в Вебмастере по данным браузеров посетителей и отчёты времени загрузки в Метрике. Влияет она через поведение: медленная страница даёт короткие визиты и возвраты в выдачу.
• В набор входят LCP — отрисовка крупнейшего элемента, CLS — совокупный сдвиг макета, INP — отзывчивость. INP заменил FID в марте 2024 года.
• Пороги заданы спецификацией и по годам не меняются: LCP до 2,5 с хорошо и свыше 4 с плохо, CLS до 0,1 и свыше 0,25, INP до 200 мс и свыше 500 мс.
• Оценка считается по 75-му процентилю реальных визитов, отдельно для мобильных и настольных.
• Балл от 0 до 100 в PageSpeed Insights в набор не входит, как и TTFB, FCP, TBT и Speed Index: это диагностика причин. INP лабораторно не измеряется вообще.
• Лабораторный прогон находит причины, но ничего не говорит о посетителях; полевые данные требуют трафика, и без него зелёный балл ничего не доказывает.
• Гонка бессмысленна в четырёх случаях: полевых данных нет, показатели в пределах порогов, проблема в отсутствии нужных страниц, силы уходят на последние баллы.
• На WordPress порядок работ такой: кэш страниц, изображения, управление сценариями, чистка подключений.
• Правки вносят по одной с замером после каждой, а результат проверяют не баллом, а отказами, возвратами в выдачу и числом обращений.