СТАТЬЯ

Почему Core Web Vitals в Google Search Console и PageSpeed Insights отличаются

07.10.2026

Вы ускорили страницу, проверили её в PageSpeed Insights — показатели стали зелёными, Performance вырос. Затем открываете Google Search Console, а там те же URL по-прежнему отмечены как проблемные.

Бывает и наоборот: в Search Console всё хорошо, а очередной запуск PageSpeed Insights показывает плохой LCP.

Это не обязательно означает ошибку одного из сервисов.

Google Search Console и PageSpeed Insights действительно работают с Core Web Vitals, но показывают данные в разном контексте и решают разные задачи. Более того, внутри самого PageSpeed Insights объединены два принципиально разных типа измерений — данные реальных посещений из CrUX и лабораторный тест Lighthouse.

Поэтому сравнивать просто две цифры LCP недостаточно. Сначала нужно понять, откуда каждая из них взялась.

Что такое Core Web Vitals

Core Web Vitals — набор метрик Google для оценки пользовательского опыта страницы по трём направлениям:

скорость отображения основного содержимого;
отзывчивость интерфейса;
визуальная стабильность.

В 2026 году в набор входят:

Метрика	Что показывает	Хорошее значение
LCP — Largest Contentful Paint	Когда появился крупнейший видимый элемент основного контента	≤ 2,5 с
INP — Interaction to Next Paint	Насколько быстро страница реагирует на взаимодействия	≤ 200 мс
CLS — Cumulative Layout Shift	Насколько стабилен макет страницы	≤ 0,1

Google оценивает Core Web Vitals по 75-му перцентилю: целевого значения или результата лучше должны достигать примерно 75% посещений страницы.

Иными словами, хороший результат должен наблюдаться примерно в трёх из четырёх посещений, а не обязательно у 75% уникальных пользователей.

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

При этом есть нюанс с полнотой данных. Например, в PageSpeed Insights при отсутствии достаточного количества данных по INP общая оценка всё ещё может быть пройдена по хорошим LCP и CLS. Если же данных недостаточно для ключевых метрик, общий статус может вообще не формироваться.

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

Что такое PageSpeed Insights

PageSpeed Insights, или PSI, — инструмент Google для анализа производительности конкретной страницы.

Главная причина путаницы заключается в том, что PSI объединяет два источника данных.

Данные реальных посещений

В верхней части отчёта могут отображаться показатели Chrome User Experience Report — CrUX.

Они отвечают на вопрос:

Какой пользовательский опыт получали реальные посетители страницы в течение последних недель?

Лабораторный тест Lighthouse

Ниже находится результат нового синтетического теста.

Lighthouse загружает страницу в контролируемой среде и анализирует её текущее техническое состояние.

Он отвечает уже на другой вопрос:

Как страница работает в условиях этого конкретного теста и что сейчас можно оптимизировать?

Поэтому верхняя и нижняя части одного отчёта PSI могут показывать разную картину — и это нормально.

Что такое CrUX

Chrome User Experience Report — набор агрегированных и обезличенных данных о реальном пользовательском опыте, собранных у подходящей выборки пользователей Chrome.

Это не данные абсолютно всех пользователей браузера.

В CrUX попадают реальные измерения при посещении сайтов в разных условиях:

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

Именно поэтому полевые показатели часто отличаются от красивого лабораторного теста на одном устройстве.

CrUX используется как источник полевых данных Core Web Vitals в PageSpeed Insights и Google Search Console.

Что показывает Google Search Console

Отчёт Core Web Vitals в GSC рассчитан прежде всего на поиск массовых проблем сайта.

Search Console объединяет похожие URL в группы.

Например, отдельную группу могут образовывать:

карточки товаров;
статьи;
страницы услуг;
страницы одного шаблона.

Поэтому URL, который GSC показывает в качестве примера, не обязательно является единственной страницей с таким результатом.

Это одна из главных причин, почему значение в Search Console способно отличаться от PageSpeed Insights для конкретного адреса.

Главное отличие GSC от PageSpeed Insights

Google Search Console	PageSpeed Insights
Анализирует состояние сайта и групп похожих URL	Помогает исследовать конкретную страницу
Использует реальные данные CrUX	Показывает CrUX и Lighthouse
Группирует похожие страницы	Может показывать данные конкретного URL
Работает с историческими полевыми данными	Полевой блок тоже исторический, Lighthouse — текущий тест
Удобен для поиска массовых проблем	Удобен для диагностики отдельной страницы
Не показывает мгновенный эффект правки	Lighthouse можно повторить сразу

Поэтому эти инструменты не конкурируют между собой.

Обычно логика работы такая:

GSC показывает, где искать проблему → PSI помогает изучить конкретную страницу → Lighthouse и DevTools помогают найти техническую причину.

Почему GSC показывает плохой LCP, а PSI — хороший

Представим, что в Search Console группа страниц имеет LCP 4,1 секунды.

Вы открываете один URL из этой группы в PSI и видите:

LCP — 2,3 секунды.

Противоречия здесь может не быть.

GSC оценивает группу похожих страниц, а полевой блок PSI может относиться к одному конкретному адресу.

Внутри группы часть страниц способна работать хуже.

Например, общий шаблон одинаковый, но:

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

Поэтому при проблеме группы полезно проверить несколько её представителей, а не только один удачный URL.

Почему в PageSpeed Insights несколько разных результатов

Одна из самых частых ситуаций:

в верхней части PSI написано, что Core Web Vitals пройдены, а ниже Lighthouse показывает невысокий Performance и жёлтый LCP.

Это нормально.

Верхний блок — полевые данные

Он показывает опыт реальных посещений за скользящий исторический период CrUX.

Нижний блок — лабораторный тест

Lighthouse запускается заново и оценивает страницу в смоделированных условиях.

Поэтому результаты могут выглядеть так:

CrUX LCP: 2,2 с
Lighthouse LCP: 3,1 с

или наоборот.

Это не две попытки измерить одну страницу в одну и ту же секунду.

Почему после ускорения сайта Search Console ещё показывает проблему

Допустим, сегодня программист:

оптимизировал главное изображение;
убрал блокирующий JavaScript;
настроил preload;
сократил серверную задержку.

После этого Lighthouse показывает LCP 1,8 секунды.

Но вчерашние и позавчерашние реальные посещения из CrUX никуда мгновенно не исчезают.

Полевые данные используют скользящее 28-дневное окно. Новые измерения постепенно заменяют старые.

Поэтому ситуация:

PageSpeed уже хороший, а Search Console несколько дней продолжает показывать проблему

сама по себе не говорит, что исправление не сработало.

Lighthouse показывает текущее состояние теста.

GSC — накопленный опыт реальных посещений за период.

Почему полевой блок PSI тоже не меняется сразу

Потому что верхняя часть PageSpeed Insights использует тот же тип исторических данных CrUX.

После оптимизации вполне возможна картина:

Источник	Результат
Lighthouse сегодня	LCP 1,7 с
PSI, реальные данные	LCP 2,9 с
GSC	Требуется улучшение

Лабораторный результат уже отражает новую версию страницы.

Полевые значения ещё содержат измерения до оптимизации.

Почему у конкретной страницы может не быть CrUX

Для полевых данных требуется достаточный объём подходящих измерений.

У новой или малопосещаемой страницы их может не хватить.

Тогда PSI способен показать не данные конкретного URL, а информацию на уровне origin, например:

https://example.ru

Если данных недостаточно даже на уровне origin, блок реального пользовательского опыта не будет доступен.

Поэтому при анализе нужно обязательно смотреть, к чему относятся показатели:

This URL / Этот URL

или:

Origin / Источник.

Иначе легко сравнить в GSC группу страниц с данными всего сайта в PSI и решить, что инструменты противоречат друг другу.

Почему проблема в GSC может не воспроизводиться на одном URL

Search Console объединяет похожие страницы.

Представим сайт услуг с 40 URL одного шаблона.

На большинстве страниц всё работает быстро, но на части размещены тяжёлые изображения первого экрана.

GSC фиксирует проблему группы.

SEO-специалист проверяет одну быструю страницу в PSI и получает хороший результат.

Вывод:

Search Console ошибается.

будет преждевременным.

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

Почему mobile и desktop показывают разные результаты

Core Web Vitals нужно анализировать отдельно для мобильных и настольных устройств.

Причины очевидны:

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

Поэтому страница может иметь хороший LCP на настольных устройствах и плохой на мобильных.

При сравнении GSC и PSI сначала убедитесь, что смотрите данные для одного типа устройств.

Почему INP трудно проверить через обычный Lighthouse

INP измеряет реакцию страницы на реальные взаимодействия:

клики;
нажатия;
ввод;
открытие меню;
работу фильтра;
действия с формой.

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

Поэтому он не измеряет INP тем же способом, что полевые данные.

В лабораторной диагностике используется TBT — Total Blocking Time как косвенный индикатор возможных проблем отзывчивости.

Но TBT и INP — не одно и то же.

Например, плохая реакция может возникать только после:

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

Стандартный автоматический тест этого действия может вообще не выполнить.

Почему CLS у реальных посетителей бывает хуже

Похожая ситуация возможна с CLS.

Lighthouse наблюдает страницу в ограниченном лабораторном сценарии.

Реальный посетитель может:

долго прокручивать страницу;
раскрывать блоки;
ждать загрузки виджета;
увидеть поздно появившийся баннер;
взаимодействовать с элементами интерфейса.

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

Поэтому хороший CLS в Lighthouse не гарантирует такого же значения в CrUX.

Почему Performance 100 не означает идеальные Core Web Vitals

Performance Score — лабораторная оценка Lighthouse.

Это полезный диагностический показатель, но его нельзя считать итоговой оценкой пользовательского опыта всего сайта.

Можно получить:

Performance 100

и при этом иметь плохой INP у реальных посетителей.

И наоборот, разовый Performance 75 ещё не означает, что сайт проваливает полевые Core Web Vitals.

Поэтому задача оптимизации — не добиться красивой цифры ради самой цифры.

Гораздо важнее устранить реальные проблемы LCP, INP и CLS.

Почему параметры URL тоже могут дать разные данные

Search Console и PageSpeed Insights не всегда одинаково работают с URL, содержащими параметры.

В GSC страницы с разными параметрами могут учитываться отдельно.

CrUX в PageSpeed Insights при формировании URL-данных может нормализовать адрес и не учитывать параметры таким же образом.

Это ещё одна причина, почему показатели вроде:

/catalog/?sort=price

в разных инструментах нельзя сравнивать механически.

Особенно это актуально для сайтов с:

фильтрами;
сортировками;
UTM-метками;
другими GET-параметрами.

Какому инструменту доверять

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

Задача	Что смотреть
Найти массовые проблемы Core Web Vitals	Google Search Console
Проверить состояние группы страниц	Google Search Console
Посмотреть реальные данные конкретного URL	Полевой блок PSI
Быстро проверить внесённую правку	Lighthouse
Найти причину плохого LCP	Lighthouse и DevTools
Разобраться с плохим INP	CrUX, реальные взаимодействия, DevTools/RUM
Проверить устойчивое улучшение	Полевые данные после накопления новых измерений

Полевые данные отвечают на вопрос:

Что происходило у реальных посетителей?

Лабораторные:

Что происходит при контролируемом тестировании сейчас?

Оба ответа нужны.

Что делать, если PSI уже зелёный, а GSC ещё красный

Проверьте по порядку:

Сравниваете ли вы полевые данные с полевыми, а не GSC с Lighthouse.
Относится ли PSI к конкретному URL или ко всему origin.
Совпадает ли тип устройства.
Когда была внесена оптимизация.
Какие ещё URL входят в проблемную группу Search Console.

Если исправление сделано недавно, некоторое расхождение с 28-дневными полевыми данными ожидаемо.

Что делать, если GSC зелёный, а Lighthouse красный

Не игнорировать лабораторный результат, но и не считать его автоматическим доказательством плохих Core Web Vitals.

Lighthouse мог выявить потенциальное слабое место страницы в конкретных тестовых условиях.

Стоит посмотреть:

какой именно показатель ухудшился;
что стало LCP-элементом;
есть ли блокирующие ресурсы;
повторяется ли результат при следующих тестах;
подтверждается ли проблема полевыми данными.

Если реальные посещения устойчиво показывают хорошие показатели, один неудачный лабораторный запуск не означает, что весь сайт перестал проходить Core Web Vitals.

Коротко: почему GSC и PSI показывают разные цифры

Главная причина — они не всегда измеряют один и тот же объект одинаковым способом.

Search Console работает с полевыми данными и группами похожих URL.

PageSpeed Insights может показывать полевые данные конкретного URL или origin, а ниже — совершенно отдельный лабораторный тест Lighthouse.

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

Разница показателей в таких условиях — нормальна.

Правильная последовательность проверки:

GSC → проблемная группа → PSI → тип полевых данных → Lighthouse / DevTools → исправление → ожидание новых CrUX-измерений.

FAQ

ВОПРОСЫ И ОТВЕТЫ

Почему у меня PageSpeed 90+, а сайт всё равно ощущается медленным на телефоне?

Баллы Lighthouse получены в лабораторном тесте и не отражают все устройства и реальные сценарии посетителей. На слабом смартфоне, мобильной сети или после взаимодействия с меню и формами сайт может вести себя хуже. Поэтому стоит сопоставить Lighthouse с полевыми данными и проверить сайт на реальном устройстве.

Что делать, если Core Web Vitals плохие только на мобильных?

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

Нужно ли срочно что-то менять, если одна страница в PSI иногда показывает красный LCP?

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

Почему после установки кеша показатели почти не улучшились?

Кеш решает только часть проблем производительности. Плохой LCP может быть связан с тяжёлым изображением, поздним обнаружением ресурса, CSS или JavaScript, а INP — с длительными задачами в браузере. Поэтому «включить кеш» и «исправить Core Web Vitals» — не одно и то же.

Может ли внешний виджет испортить Core Web Vitals, хотя сам сайт оптимизирован?

Да. Онлайн-чат, карта, система аналитики, рекламный код, форма обратного звонка или другой сторонний скрипт могут блокировать основной поток, вызывать смещения или замедлять взаимодействия. Поэтому при диагностике нужно смотреть не только код темы и сервера, но и всё, что загружается со сторонних доменов.