Core Web Vitals assessment: Failed - как читать отчёт Search Console и что чинить первым (2026)

Отчёт Core Web Vitals - одно из немногих мест, где Google прямо говорит о сайте «прошёл» или «не прошёл», и именно поэтому красное Failed вызывает больше паники и больше бессмысленной работы, чем почти любое другое сообщение в Search Console. Отчёт не является оценкой скорости и не является мнением о вашем коде. Это агрегат того, что реальные пользователи Chrome испытали на ваших страницах за последние 28 дней, сжатый до трёх порогов. Прочитать его правильно - примерно десять минут работы, и это избавляет от куда более частого исхода: команда шесть недель жмёт картинки, тогда как провалилась метрика задержки отклика. По данным HTTP Archive 2025 Web Almanac, 43% мобильных источников до сих пор не проходят INP, и INP - единственная метрика, которую лабораторный тест не показывает вообще. Здесь разбирается, что именно оценивается, как определить провалившуюся метрику и стоящий за ней шаблон страниц, почему статус отстаёт от исправления на недели, во что провал обходится в позициях и в выручке, и где проходит граница между починкой силами вашей команды и инженерной задачей.

Что на самом деле означает «Core Web Vitals assessment: Failed»?

Оценка - это вердикт по группе URL, построенный на Chrome User Experience Report (CrUX). CrUX собирает измерения с реальных пользователей Chrome, согласившихся на передачу статистики, на реальных устройствах и реальных сетях. Search Console берёт 28 дней этих данных, группирует URL по структурному сходству (на практике - по шаблону страницы) и считает 75-й перцентиль каждой метрики для каждой группы. Группа проходит, только если все три метрики попадают в зону «Good» на этом перцентиле. Одна метрика вне зоны обрушивает всю группу, а мобильные и десктоп оцениваются как независимые наборы данных, поэтому сайт может проходить на десктопе и проваливаться на мобильных при одинаковом коде. Слово Failed несёт узкий и точный смысл: как минимум одно из трёх конкретных чисел, измеренных не менее чем на четверти реальных визитов, оказалось за порогом, который Google опубликовал заранее.

• LCP (Largest Contentful Paint): Good ≤ 2.5с, требует улучшения 2.5–4.0с, плохо > 4.0с. Показывает, когда дорисовался самый крупный видимый элемент в области просмотра. Это ближайшее техническое соответствие ощущению «страница загрузилась».
• INP (Interaction to Next Paint): Good ≤ 200мс, требует улучшения 201–500мс, плохо > 500мс. Измеряет задержку взаимодействий на протяжении всей сессии, отчёт идёт примерно по 98-му перцентилю взаимодействий одного пользователя. Заменила FID в составе Core Web Vitals 12 марта 2024 года.
• CLS (Cumulative Layout Shift): Good ≤ 0.1, требует улучшения 0.1–0.25, плохо > 0.25. Измеряет неожиданные смещения видимого контента за время жизни страницы, считается как безразмерное произведение доли влияния и доли расстояния.
• Правило 75-го перцентиля: Метрика считается хорошей для группы URL, только если как минимум 75% подходящих визитов дали хорошее значение. Оптимизация под собственное устройство на собственном канале ничего не говорит о тех 25% хвоста, которые и решают исход.
• Раздельные вердикты по устройствам: Провалы концентрируются на мобильных, потому что выборка CrUX состоит преимущественно из среднебюджетного Android, а не из ноутбука, на котором сайт тестировали.

Почему PageSpeed Insights показывает 95, а Search Console пишет Failed?

Потому что PageSpeed Insights помещает два несвязанных измерения на один экран, а большинство читает только цветной кружок. Верхний блок, когда он есть, - полевые данные CrUX: то самое 28-дневное распределение реальных пользователей, которое оценивает Search Console. Крупный балл под ним - Lighthouse, один синтетический прогон на эмулированном среднем устройстве с придушенными процессором и сетью, выполненный прямо сейчас, без единого живого человека на странице. Эти два числа расходятся регулярно, и оба при этом верны. Главный структурный разрыв - INP: в лабораторном прогоне нет реальных взаимодействий, которые можно замерить, поэтому Lighthouse не выдаёт значение INP вообще и подставляет Total Blocking Time как грубый заменитель. Страница может набрать 100 в лаборатории и иметь 600мс INP в поле, и лабораторный балл не предупредит об этом никак. Одно правило снимает почти всю путаницу: полевые данные определяют вашу оценку, лабораторные нужны только для отладки.

• Лабораторные данные (балл Lighthouse): Один прогон, эмулированное среднее устройство, искусственное ограничение сети, ноль взаимодействий, ноль расширений, ноль разброса по холодному кэшу. Полезно для воспроизведения проблемы и для регрессионных проверок в CI. Никогда не является основанием оценки.
• Полевые данные (CrUX): 28 дней реальных сессий на фактическом распределении устройств, сетей, географий и браузерных расширений ваших посетителей. Именно это оценивает Search Console и именно это потребляют ранжирующие системы Google.
• INP существует только в поле: Lighthouse вместо неё показывает Total Blocking Time. TBT коррелирует с INP, но измеряется во время загрузки, тогда как INP измеряется по всей сессии, включая клики по фильтрам и тапы по меню, которые происходят сильно позже загрузки.
• URL против домена: PageSpeed Insights откатывается к полевым данным уровня домена, когда у конкретного URL слишком мало выборки. Вы можете смотреть на главную, а число на экране будет средним по всем страницам домена.
• Практическая проверка: Если лабораторный балл зелёный, а оценка красная, откройте блок полевых данных и прочитайте три полосы. В большинстве случаев виновата INP или CLS, и ни одна из них не видна в крупном числе сверху.

Какая из трёх метрик провалилась и как это проверить?

Search Console отвечает на это прямо, но ответ лежит в строках проблем, а не в графике сверху. Откройте Core Web Vitals, выберите «Мобильные» или «Десктоп» и прочитайте список проблем под графиком. Каждая строка сформулирована как метрика, порог и устройство, например «Проблема с LCP: более 2,5 с (мобильные)», и несёт счётчик затронутых URL. Клик по строке раскрывает примеры URL, и именно примеры ценнее всего, потому что показывают, какой шаблон страниц проваливается. Провалы группируются по шаблонам, а не рассыпаются случайно, поэтому один макет листинга товаров или один макет статьи обычно объясняет всю группу целиком. Подтвердите диагноз на одном показательном URL в PageSpeed Insights, читая блок полевых данных, а не балл, и если выборка выглядит тонкой, CrUX API вернёт полную гистограмму для любого URL или домена.

• Начинайте со строк проблем, а не с графика: График показывает, сколько URL попало в каждую зону. Строки называют метрику и порог, которые дали вердикт.
• Используйте примеры URL как карту шаблонов: Сгруппируйте их по паттерну адреса. Если все проваленные примеры лежат в /collections/* или /blog/*, у вас один макет для починки, а не сотни страниц.
• Проверяйте по URL в PageSpeed Insights: Читайте блок «Узнайте, как ваш сайт работает у реальных пользователей». Балл под ним - отдельное измерение, и он не подтверждает и не опровергает оценку.
• Тяните сырую гистограмму, когда выборка тонкая: https://chromeuxreport.googleapis.com/v1/records:queryRecord принимает URL или домен и возвращает полное распределение, включая то самое значение p75, которое использовал Search Console.
• Снимайте метрики со своих сессий: Официальная библиотека web-vitals реализует те же алгоритмы, что и CrUX. Отправка onLCP, onINP и onCLS в вашу аналитику даёт атрибуцию, которой у CrUX нет: какой элемент, какой маршрут, какое взаимодействие.

Если нужны три полевых значения, лабораторные метрики и стоящие за ними проблемы страницы за один проход, бесплатный аудит сайта прогоняет эти проверки по любому URL и возвращает их вместе, включая проверку того, есть ли у вашего домена полевые данные в CrUX вообще.

Почему отчёт всё ещё показывает Failed через недели после починки?

Потому что оценка считается по скользящему окну в 28 дней, а деплой не меняет задним числом сессии, которые уже внутри этого окна. В день выкатки исправления окно по-прежнему содержит 28 дней визитов до починки. Каждый следующий день выбрасывает один день старых данных и добавляет один день новых, поэтому 75-й перцентиль улучшается постепенно и доходит до истинного значения примерно через четыре недели. Search Console сверху добавляет собственную задержку обработки в несколько дней. Это отставание - самое дорогое непонимание во всём отчёте, потому что естественное прочтение неизменившегося красного статуса звучит как «починка не сработала», и команда идёт менять ещё код, окончательно теряя возможность что-либо атрибутировать. Правильная реакция на красный статус через две недели после деплоя - проверить исправление на свежих данных, а не чинить заново.

• Рассчитывайте примерно на четыре недели до полного эффекта: Частичное движение видно уже через несколько дней по мере вымывания старых сессий, но итоговому числу нельзя доверять, пока окно не сменится полностью.
• Search Console отстаёт от CrUX: Отчёт отражает данные, которым уже несколько дней. Проверка на той же неделе не говорит вообще ни о чём.
• Кнопку «Проверить исправление» используйте осознанно: Она запускает наблюдаемую 28-дневную переоценку затронутых URL. Ничего не ускоряет, но создаёт датированную отметку о том, когда вы заявили починку, что важно, если работа растянулась на несколько деплоев.
• Смотрите тем временем на собственный RUM: Полевые замеры через web-vitals показывают эффект деплоя за часы, на вашем трафике, без 28-дневного сглаживания. Это единственная быстрая обратная связь, которая существует.
• Не наваливайте исправления вслепую: Три новых изменения во время окна валидации делают невозможным понять, какое из них сдвинуло число, а какое вызвало регресс.

Действительно ли проваленная оценка Core Web Vitals бьёт по позициям в Google?

Слабее, чем подразумевает большинство статей на эту тему, и здесь стоит быть точным, потому что преувеличение ведёт к плохим бюджетным решениям. Page experience, измеримой частью которого являются Core Web Vitals, - реальный вход ранжирующих систем Google, но работает он как различитель между результатами сопоставимой релевантности, а не как первичный фактор. Быстрая страница с пустым содержанием не обойдёт более медленную, которая нормально отвечает на запрос. Если ваши страницы не ранжируются, Core Web Vitals редко является причиной, и работа над скоростью не починит проблему контента или авторитетности. Где провал стабильно стоит денег, так это после клика: медленные и прыгающие страницы теряют пользователей на каждом шаге воронки, и эта потеря совершенно не зависит от вашей позиции. Честная формулировка такая: Core Web Vitals - вопрос конверсии и удержания, к которому прилагается скромный бонус в ранжировании, и финансировать эту работу нужно по первому основанию, а не по второму.

• Различитель, а не рычаг: Собственные рекомендации Google позиционируют page experience как полезный тогда, когда остальные сигналы сопоставимы. Считайте прирост позиций возможным побочным эффектом, а не бизнес-обоснованием.
• Аргумент выручки сильнее аргумента позиций: Отказы растут с временем загрузки и с нестабильностью независимо от места в выдаче. Эффект распространяется и на платный, и на почтовый, и на прямой трафик, которым ваша позиция безразлична.
• Провалы концентрируются там, где намерение выше всего: Проблемы INP обычно всплывают на фильтрах, поиске по сайту, выборе вариантов товара и действиях с корзиной, то есть ровно там, где посетитель уже решил купить.
• Сначала диагноз, потом бюджет: Если органика стоит на месте и позиции плохие, аудируйте сначала контент, перелинковку и индексацию. Работа над Core Web Vitals на сайте без релевантного контента - дорогое украшение.
• По теме: О сигналах ранжирования, которые обычно значат больше, есть руководство по JSON-LD, а полная картина по скорости - в руководстве по веб-производительности.

Что делать, если Search Console вообще не показывает данные Core Web Vitals?

Это проблема размера выборки, а не наказание, и для большой доли сайтов это нормальное состояние. CrUX начинает отчитываться по URL или домену только после того, как собрал достаточно подходящих визитов от согласившихся пользователей Chrome, чтобы построить статистически значимое распределение и не раскрыть поведение отдельного человека. Небольшие сайты часто видят отсутствие данных на уровне URL, только данные уровня домена или данные, которые появляются и исчезают вместе с колебаниями трафика. Ни на что в ранжировании это не влияет, и никакая оптимизация не заставит данные появиться быстрее, потому что ограничение здесь в объёме трафика, а не в качестве страниц. Практическое следствие: Search Console не может быть вашей обратной связью, поэтому её придётся построить самостоятельно.

• Сначала посмотрите, что вообще есть: Запросите CrUX API и по URL, и по домену. Данные уровня домена часто существуют там, где данных по URL нет, и они остаются законным сигналом о ваших шаблонах.
• Снимайте метрики с реальных пользователей сами: npm install web-vitals, затем отправляйте onLCP, onINP и onCLS в аналитику. Даже несколько сотен сессий в неделю дают пригодный 75-й перцентиль задолго до того, как это сделал бы CrUX.
• Пользуйтесь лабораторными данными честно: Lighthouse на придушенном среднем профиле - разумный заменитель для LCP и CLS. Для INP он заменителем не является, поэтому реальные взаимодействия проверяйте руками на настоящем среднебюджетном Android.
• Не гоняйтесь за зелёным лабораторным баллом: Без полевых данных лабораторное число - единственная доступная обратная связь, и потому появляется соблазн оптимизировать прямо под него. Этот путь заканчивается идеальным баллом и сайтом, который в руках всё равно ощущается медленным.

Какие провалы можно починить своими силами, а где нужен инженер?

Граница проходит по тому, меняет ли исправление настройку и файл или же меняет способ построения страницы. Большинство провалов CLS и заметная доля провалов LCP лежат на первой стороне и реально чинятся грамотной маркетинговой командой за полдня: раздутая картинка в первом экране, отсутствующие ширина и высота у встраиваемого блока, баннер, вставляемый в первый экран после загрузки, шрифт, блокирующий отрисовку. Провалы INP там почти никогда не лежат. Задержка отклика - это свойство того, сколько JavaScript выполняется в главном потоке и когда именно, а значит починка живёт внутри архитектуры компонентов, стратегии гидратации и бюджета сторонних скриптов, и ни до чего из этого нельзя дотянуться из панели настроек. Полезный вопрос перед выделением бюджета звучит не «насколько плох балл», а «в какую из двух категорий попадает мой провал», потому что ответ меняет стоимость на порядок.

• Обычно чинит ваша команда: Несжатые или избыточно большие картинки первого экрана; отсутствие атрибутов width и height у изображений, iframe и рекламных блоков; поздно вставляемые cookie-баннеры и промо-полосы; настройка font-display, блокирующая первую отрисовку; неиспользуемые приложения, пиксели и контейнеры тег-менеджера; хостинг без CDN перед ним.
• Требует инженера: INP, вызванная стоимостью гидратации или размером бандла; элемент LCP, который рендерится на клиенте и потому не может начать загружаться до выполнения JavaScript; блокирующие отрисовку сторонние скрипты, которые нельзя просто удалить по бизнес-причинам; смещения макета, рождающиеся в дереве компонентов, а не в одном файле; переписывание шаблонов там, где проблема в самой структуре страницы.
• Быстрый диагностический признак: Если провалилась CLS, начинайте со своей команды. Если INP, начинайте с инженера. Если LCP, посмотрите, что именно является самым крупным элементом: картинка обычно ваша, клиентски отрисованный блок обычно нет.
• По теме: Об архитектурном разборе пути отрисовки и отклика за проваленной оценкой - услуга Core Web Vitals и оптимизация производительности. Инженерные детали именно по INP - в руководстве по оптимизации INP.

В каком порядке чинить проблемы Core Web Vitals?

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

• 1. Подтвердите цель. Назовите провалившуюся метрику, устройство и шаблон до того, как трогать код. Починка не той метрики даёт зелёный лабораторный балл и неизменившуюся оценку.
• 2. Почините CLS. Зарезервируйте размеры у каждого изображения, iframe, встраиваемого блока и рекламного места. Вынесите вставляемые баннеры из потока макета или отрисовывайте их на сервере с уже выделенным местом. Грузите шрифты с сопоставленным по метрикам запасным вариантом, чтобы подмена не перекладывала текст.
• 3. Почините LCP. Определите элемент LCP в DevTools, затем сделайте его обнаружимым в исходном HTML, корректно размерным, отданным в современном формате и приоритетным. Если он рендерится на клиенте, перенос его в серверную отдачу обычно даёт больше, чем любая оптимизация файла.
• 4. Почините INP. Сократите и отложите JavaScript в главном потоке, разбейте длинные задачи на границах взаимодействий, изолируйте сторонние скрипты и сузьте поверхность гидратации. Это архитектурная работа, и её место последнее, когда измерение уже не загрязнено первыми тремя шагами.
• 5. Измеряйте в поле и ждите. Подтвердите изменение в собственном RUM за несколько дней, затем дайте 28-дневному окну смениться, прежде чем читать оценку как вердикт.

Сколько времени нужно, чтобы оценка снова стала зелёной?

От четырёх до шести недель с того деплоя, который действительно чинит провалившуюся метрику, при условии что исправление верное и за ним ничего не регрессировало. Нижнюю границу задаёт 28-дневное окно CrUX, сократить которое нельзя, плюс собственная задержка обработки Search Console в несколько дней. На практике срок растягивается, когда первое исправление целится не в ту метрику, что бывает часто, или когда изменение улучшает медиану, не сдвигая 75-й перцентиль, - это специфическая ловушка тестирования на хорошем железе и быстром канале. Сайты с тонким покрытием в CrUX вдобавок могут какое-то время перескакивать между состояниями из-за колебаний выборки. Планируйте работу как один деплой плюс месяц ожидания, а не как месяц итераций, и используйте собственные полевые замеры для обратной связи в промежутке.

Заключение

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

Проверьте свои числа: бесплатный аудит сайта возвращает ваши полевые данные, лабораторные метрики и стоящие за ними проблемы страницы по любому URL, без регистрации. Если провал окажется архитектурным, услуга Core Web Vitals и оптимизация производительности закрывает работу с отрисовкой и откликом, а обсудить, что именно показывает ваш отчёт, можно на консультации.

Источники

• Google web.dev - Core Web Vitals
• Справка Search Console - отчёт Core Web Vitals
• Google web.dev - Largest Contentful Paint (LCP)
• Google web.dev - Interaction to Next Paint (INP)
• Google web.dev - Cumulative Layout Shift (CLS)
• Chrome UX Report - документация API
• Google web.dev - различия лабораторных и полевых данных
• HTTP Archive - 2025 Web Almanac, глава Performance
• Google Search Central - о page experience
• Библиотека web-vitals на GitHub