Подробнее
Скорость и удобство сайта долго оценивали на глаз или по синтетическим тестам, которые мало говорили о реальных посетителях. Google предложил единый набор измеримых показателей и включил их в группу сигналов удобства страницы (page experience) вместе с мобильной адаптацией и HTTPS. Данные берутся из Chrome User Experience Report (CrUX) — обезличенной статистики пользователей Chrome, которые согласились её передавать. Поэтому CWV описывают не то, как сайт грузится у разработчика на мощном ноутбуке, а то, что видит ваша аудитория на своих телефонах и сетях.
Состав метрик меняется: INP заменил FID в марте 2024 года. FID учитывал только задержку первого взаимодействия, а INP оценивает отзывчивость на протяжении всего визита — и честнее показывает страницы с тяжёлым JavaScript. Влияние CWV на позиции Google называет умеренным: при сопоставимом по полезности контенте выигрывает удобная страница, но хорошая скорость не вытянет материал, который не отвечает на запрос. Это часть технического SEO, а не замена ему.
Три метрики и их пороги
У каждой метрики три зоны. Оценка идёт по 75-му процентилю полевых данных — то есть порог должен выполняться как минимум у трёх посещений из четырёх, отдельно для мобильных устройств и для десктопа.
| Метрика | Что измеряет | Хорошо | Требует улучшения | Плохо |
|---|---|---|---|---|
| LCP — Largest Contentful Paint | Время отрисовки крупнейшего видимого элемента первого экрана | ≤ 2,5 с | 2,5–4 с | > 4 с |
| INP — Interaction to Next Paint | Задержку между действием пользователя и визуальным откликом | ≤ 200 мс | 200–500 мс | > 500 мс |
| CLS — Cumulative Layout Shift | Суммарные неожиданные сдвиги вёрстки | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Страница проходит оценку, когда все три метрики в зелёной зоне. В Search Console статус группы адресов определяется худшей из метрик: отличный LCP не компенсирует плохой CLS.
Откуда берутся данные: поле и лаборатория
Главная путаница вокруг CWV возникает из-за того, что одни и те же метрики измеряются двумя принципиально разными способами.
- Полевые данные (CrUX) — реальные визиты пользователей Chrome за последние 28 дней. Именно их Google использует в оценке удобства страниц. Если у конкретного URL мало трафика, PageSpeed Insights покажет данные по всему сайту, а при нехватке и их полевого блока не будет.
- Лабораторные данные (Lighthouse) — один прогон на эмулированном устройстве с заданной скоростью сети. Результат воспроизводим и удобен для поиска причин, но не отражает вашу аудиторию. В лаборатории нет реальных кликов, поэтому вместо INP ориентируются на Total Blocking Time — время, когда основной поток занят и страница не реагирует.
- Собственный сбор (RUM) — библиотека web-vitals отправляет метрики из браузеров посетителей в вашу аналитику. Это нужно, когда важно видеть показатели по шаблонам, сегментам и сразу после релиза, не дожидаясь 28-дневного окна CrUX.
Что ломает каждую метрику
У каждой метрики свои типовые виновники, и чинить их стоит в порядке вклада.
LCP портят тяжёлая обложка первого экрана (не сжата, в старом формате, без приоритетной загрузки), медленный ответ сервера и веб-шрифты, блокирующие отрисовку. Помогают сжатие и современные форматы изображений, кэш и CDN, предзагрузка ключевого ресурса и отказ от ленивой загрузки для картинки первого экрана.
INP страдает от тяжёлого JavaScript: долгой гидрации фреймворка, обработчиков на каждый ввод, сторонних скриптов аналитики и чатов в основном потоке. Лечат разбиением длинных задач, отложенной загрузкой второстепенных скриптов и отказом от лишних виджетов.
CLS ломают изображения и iframe без заданных размеров, рекламные блоки и баннеры, которые вставляются над контентом после загрузки, и поздняя подмена шрифта со сдвигом строк. Решение — резервировать место заранее и не толкать контент вниз.
Отдельное предостережение: агрессивные «ускорители» — автоматический инлайн критического CSS, ленивая загрузка всего подряд — нередко улучшают LCP ценой скачков вёрстки. После каждой такой оптимизации CLS перепроверяют на мобильных и десктопных вьюпортах отдельно.
Зачем это бизнесу и при чём здесь нейропоиск
При продвижении в Google CWV — один из сигналов удобства, который работает на равных условиях: когда несколько страниц одинаково хорошо отвечают на запрос, преимущество получает более удобная. Но главный эффект скорости — не в ранжировании, а в поведении людей. Медленный первый экран и прыгающие кнопки раздражают, мешают оформить заказ и заставляют возвращаться в выдачу. Поэтому работа над CWV полезна и там, где сами метрики напрямую не учитываются: в Яндексе они не используются как отдельный сигнал, но скорость и стабильность отражаются на поведенческих факторах и конверсии.
Прямой связи Core Web Vitals с попаданием в нейроответы не установлено: ИИ-краулеры не измеряют INP вашей страницы. Реальная связь проходит через техническую доступность контента. Если текст появляется только после выполнения тяжёлого JavaScript, а сервер отвечает медленно, ИИ-краулеры и поисковые роботы могут не получить содержимое целиком — не все из них выполняют скрипты. Решения, которые улучшают LCP и INP, — серверный рендеринг основного контента, лёгкий клиентский код — одновременно снимают проблемы рендеринга JavaScript.
Пример из практики: контентный сайт с рекламой
Типичная ситуация: информационный проект зарабатывает на рекламе. В Search Console мобильные адреса статей помечены как проблемные по CLS, а Lighthouse в PageSpeed Insights показывает зелёные цифры, и команда не понимает, чему верить.
Разгадка в разнице измерений. Лабораторный тест фиксирует сдвиги только во время загрузки, а полевые данные учитывают весь визит: реальные посетители прокручивают статью, и рекламные блоки, подгружаясь по мере прокрутки, раздвигают текст. Чтобы поймать это, страницу открывают в Chrome DevTools, прокручивают и смотрят, какие элементы сдвигаются. Исправления понятные: под каждый рекламный слот резервируется высота, баннеры больше не вставляются над уже видимым текстом, закреплённая панель накладывается поверх контента, а не сдвигает его, для шрифтов подбирается запасной вариант с близкими метриками. После выкладки в отчёте Search Console запускают проверку исправления и ждут, пока обновятся полевые данные за новое 28-дневное окно.
Как проверить Core Web Vitals
Порядок проверки — от общей картины по сайту к конкретной причине на конкретной странице:
- Отчёт «Основные интернет-показатели» в Google Search Console. Показывает группы похожих адресов с проблемами отдельно для мобильных и десктопа. С него начинают, чтобы понять масштаб: проблема в одном шаблоне или по всему сайту. После исправлений здесь же запускают проверку.
- PageSpeed Insights. Верхний блок — полевые данные CrUX за 28 дней по URL или по всему сайту, вкладки для мобильных и десктопа. Ниже — лабораторный прогон Lighthouse с диагностикой: какой элемент стал LCP, какие скрипты блокируют поток. Балл Lighthouse не равен статусу CWV.
- Chrome DevTools. Панель Performance показывает живые значения LCP, INP и CLS прямо во время работы со страницей: можно кликнуть по фильтру каталога и увидеть, какое действие даёт медленный отклик, или прокрутить страницу и найти сдвигающийся блок.
- История и мониторинг. Для динамики по месяцам используют данные CrUX через API, для контроля после каждого релиза — собственный сбор через web-vitals.
Короткий ответ о метриках без технических деталей — на странице «Что такое Core Web Vitals», практический план ускорения — в статье «Как ускорить сайт и пройти Core Web Vitals». Если проблема сидит в шаблонах и серверной части, её находят в ходе технического аудита с приоритетами по влиянию на трафик и заявки.