Lighthouse показывает 90+, а Core Web Vitals не пройдены: почему так
Разбираю, почему зелёный лабораторный балл может расходиться с полевыми метриками, как сопоставить одинаковые условия и найти причину без догадок.
В этой статье
В PageSpeed Insights легко увидеть приятную картину: лабораторный Lighthouse окрашен в зелёный и показывает 90 баллов или больше, а выше написано, что оценка Core Web Vitals не пройдена. Исправлять всё подряд в такой ситуации не стоит. Эти части отчёта отвечают на разные вопросы.
Короткий ориентир такой: Lighthouse показывает один синтетический запуск в заданных условиях и сводит несколько лабораторных метрик в общий балл. Core Web Vitals в полевой части PageSpeed Insights описывают распределение реальных посещений за скользящие 28 дней и оцениваются по 75-му процентилю. Зелёный лабораторный балл не опровергает медленный опыт части посетителей — и наоборот.
Сначала определите, какое число вы сравниваете
В справке PageSpeed Insights Google разделяет отчёт на лабораторные данные Lighthouse и полевые данные Chrome User Experience Report, или CrUX. У них различаются источник, период и смысл результата.
Performance 90–100 — общий лабораторный балл Lighthouse. Он рассчитывается как взвешенная комбинация нескольких метрик одного моделируемого запуска.
Полевые LCP, INP и CLS — агрегированные данные реальных пользователей Chrome. При достаточном количестве данных по всем трём метрикам для прохождения оценки их значения должны попадать в рекомендуемые границы на 75-м процентиле. Если данных INP недостаточно, PageSpeed Insights оценивает LCP и CLS. Если недостаточно данных LCP или CLS, оценка недоступна.
Полевой блок может относиться к точному URL или ко всему источнику (origin). Эти уровни нельзя молча считать одной и той же страницей.
Состав общего балла и веса метрик описаны в документации Lighthouse. Отсюда важная граница: балл 90+ — не четвёртая метрика Core Web Vitals и не сертификат прохождения LCP, INP и CLS.
Почему лаборатория и поле расходятся
Лаборатория специально уменьшает число переменных: один профиль устройства, один сетевой сценарий, одна география и один запуск страницы. Это удобно для диагностики и сравнения изменений. Но реальные посетители приходят с разными телефонами, сетями, кэшем, состоянием авторизации и поведением.
В разборе различий лабораторных и полевых данных Google прямо показывает, что расхождение само по себе не ошибка отчёта. Полевое значение — точка в распределении множества посещений, а лабораторное — один наблюдаемый сценарий.
Есть и различие в самих показателях. Lighthouse использует Total Blocking Time как лабораторный сигнал отзывчивости, тогда как полевые Core Web Vitals включают INP, которому нужны реальные взаимодействия. Лабораторный CLS может не увидеть сдвиг, возникающий через несколько секунд после загрузки или после действия пользователя. А LCP одного запуска не обязан совпадать с 75-м процентилем за 28 дней.
Учебный расчёт: почему большинства быстрых визитов может быть мало
Представим 100 посещений одной страницы. В учебной выборке у 74 посещений LCP равен 2,0 секунды, а у 26 — 3,2 секунды. Если расположить значения по возрастанию, 75-е наблюдение уже окажется в группе 3,2 секунды. Значит, 75-й процентиль не попадёт в «хорошую» границу 2,5 секунды, хотя почти три четверти визитов были быстрыми.
Это упрощённая модель, а не пересчёт конкретного отчёта CrUX: реальные инструменты агрегируют гораздо больше наблюдений и используют собственную обработку распределения. Но логика выбора 75-го процентиля именно так отделяет «быстро у большинства» от «быстро почти у трёх из четырёх и лучше». Метод выбора описан в справке о порогах Core Web Vitals.
Как искать причину без спора с цифрами
Зафиксируйте источник данных: полевой CrUX или лабораторный Lighthouse, точный URL или origin, мобильные или компьютеры, даты 28-дневного периода и время лабораторного запуска.
Сравнивайте одноимённые метрики. LCP сопоставляйте с LCP, CLS с CLS. INP не приравнивайте к TBT: лабораторный показатель помогает искать блокировки главного потока, но не воспроизводит распределение реальных взаимодействий.
Повторите лабораторный запуск несколько раз с одинаковыми настройками и сохраните не только общий балл, но и значения метрик, окружение и найденный элемент LCP. Один удачный запуск полезен как след, но слаб как доказательство стабильности.
Проверьте, кому именно медленно: мобильным устройствам, отдельному шаблону, авторизованным пользователям, определённой географии или страницам с тяжёлым каталогом. Если доступна собственная RUM-аналитика, сегментируйте её теми же условиями.
Исправляйте подтверждённый механизм. Большое изображение LCP, поздний баннер, длинная задача JavaScript и очередь на сервере требуют разных действий; общий балл не выбирает решение за вас.
Если проблема появляется только при нагрузке, пригодится отдельный расчёт ресурсов VPS для магазина. Он не заменяет полевые Web Vitals, но помогает проверить серверную часть сценария, не смешивая её с устройством и сетью посетителя.
Когда можно считать вывод обоснованным
Разница между Lighthouse и полем становится полезной после формулировки проверяемой гипотезы. Например: «полевой LCP ухудшают мобильные посещения карточек товара, а лабораторный запуск проверял главную страницу на другом профиле устройства». Затем нужны одинаковый набор URL, одинаковый форм-фактор, сохранённый период и наблюдение после конкретного изменения.
У полевых данных есть инерция: PageSpeed Insights показывает скользящее окно за предыдущие 28 дней, поэтому исправление сегодня не обязано полностью изменить показатель завтра. Лаборатория, напротив, может показать эффект сразу, но только в своём сценарии.
Я бы начала не с вопроса «какой цифре верить», а с вопроса «какую аудиторию и какой период описывает каждая цифра». Lighthouse удобен для воспроизводимой диагностики. Полевые данные показывают распределение реального опыта. Решение появляется там, где совпали URL, устройство, метрика и причина — без обещания, что один зелёный балл автоматически улучшит поисковые позиции.
PageSpeed Insights can present an encouraging picture: the Lighthouse lab result is green and scores 90 or more, while the section above says the Core Web Vitals assessment has failed. There is no need to start changing everything at once. These parts of the report answer different questions.
The key distinction is this: Lighthouse shows a single synthetic run under specified conditions and combines several lab metrics into an overall score. Core Web Vitals in the field section of PageSpeed Insights describe the distribution of real visits over a rolling 28-day period and are assessed at the 75th percentile. A green lab score does not invalidate the slow experience of some visitors — and the reverse is also true.
First, identify which number you are comparing
In its PageSpeed Insights documentation, Google separates the report into Lighthouse lab data and field data from the Chrome User Experience Report, or CrUX. Their sources, reporting periods, and the meaning of the results differ.
Performance 90–100 is the overall Lighthouse lab score. It is calculated as a weighted combination of several metrics from one simulated run.
Field LCP, INP, and CLS are aggregated data from real Chrome users. When sufficient data is available for all three metrics, their values must meet the recommended thresholds at the 75th percentile to pass the assessment. If INP data is insufficient, PageSpeed Insights assesses LCP and CLS. If LCP or CLS data is insufficient, the assessment is unavailable.
The field section may cover the exact URL or the whole origin. These levels must not be silently treated as the same page.
The overall score's composition and metric weights are described in the Lighthouse documentation. This establishes an important distinction: a score of 90+ is not a fourth Core Web Vitals metric and does not certify passing results for LCP, INP, and CLS.
Why lab and field data differ
Lab testing deliberately reduces the number of variables: one device profile, one network scenario, one geographic location, and one page load. This is useful for diagnosis and comparing changes. Real visitors, however, arrive with different phones, networks, caches, login states, and behaviour.
In its explanation of the differences between lab and field data, Google makes clear that a discrepancy does not in itself indicate an error in the report. A field value is a point in a distribution of many visits, while a lab value represents one observed scenario.
The metrics themselves also differ. Lighthouse uses Total Blocking Time as a lab indicator of responsiveness, whereas field Core Web Vitals include INP, which requires real interactions. Lab CLS may miss a shift that occurs several seconds after loading or after a user action. And LCP from one run does not have to match the 75th percentile over 28 days.
Worked example: why a majority of fast visits may not be enough
Imagine 100 visits to one page. In this sample, 74 visits have an LCP of 2.0 seconds and 26 have an LCP of 3.2 seconds. If the values are sorted in ascending order, the 75th observation already falls into the 3.2-second group. The 75th percentile therefore misses the good threshold of 2.5 seconds, even though almost three quarters of visits were fast.
This is a simplified model, not a recalculation of a particular CrUX report: real tools aggregate far more observations and apply their own processing to the distribution. But this is how selecting the 75th percentile distinguishes fast for a majority from fast for roughly three in four or more. The method is described in the Core Web Vitals thresholds documentation.
How to find the cause without arguing with the numbers
Record the data source: field CrUX or lab Lighthouse, the exact URL or origin, mobile or desktop, the dates of the 28-day period, and the time of the lab run.
Compare corresponding metrics: LCP with LCP and CLS with CLS. Do not equate INP with TBT: the lab metric helps identify main-thread blocking, but does not reproduce the distribution of real interactions.
Repeat the lab run several times with identical settings and save not only the overall score, but also the metric values, the environment, and the identified LCP element. One successful run is a useful clue, but weak evidence of consistency.
Find out exactly who experiences slow performance: mobile users, users of a particular template, logged-in users, people in a particular geographic area, or visitors to pages with a large catalogue. If you collect your own RUM data, segment it using the same conditions.
Fix the confirmed mechanism. A large LCP image, a late banner, a long JavaScript task, and a server queue require different actions; the overall score does not choose a solution for you.
If the problem occurs only under load, a separate VPS resource calculation for a store may help. It does not replace field Web Vitals, but helps examine the server side of the scenario without conflating it with the visitor's device and network.
When a conclusion is justified
The difference between Lighthouse and field data becomes useful once you formulate a testable hypothesis. For example: mobile visits to product pages are worsening field LCP, while the lab run tested the home page with a different device profile. You then need the same set of URLs, the same form factor, a recorded reporting period, and observations after a specific change.
Field data takes time to reflect changes: PageSpeed Insights shows a rolling window covering the previous 28 days, so a fix today may not be fully reflected in tomorrow's metric. Lab testing, by contrast, can show the effect immediately, but only within its own scenario.
I would start by asking which audience and period each number describes, rather than which number to trust. Lighthouse is useful for reproducible diagnosis. Field data shows the distribution of real experiences. A solution emerges when the URL, device, metric, and cause align — without promising that a single green score will automatically improve search rankings.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.