PageSpeed хороший, а пользователям медленно: как сравнить лабораторные и реальные данные

Хороший Lighthouse — результат контролируемого теста, а не гарантия быстрой работы у всех посетителей. Разбираем, как сопоставить его с реальными Core Web Vitals и найти проблемный сегмент.

Хороший результат PageSpeed Insights не означает, что сайт быстрый у каждого посетителя. Lighthouse проверяет страницу один раз в заданных условиях, а полевые Core Web Vitals описывают множество реальных посещений с разными устройствами, сетями и сценариями.

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

Почему зелёный Lighthouse и жалобы пользователей не противоречат друг другу

В PageSpeed Insights соседствуют два разных вида измерений:

  • лабораторные данные Lighthouse — контролируемый запуск страницы на одном профиле устройства и сети;
  • полевые данные CrUX — агрегированные измерения реальных пользователей Chrome за предыдущие 28 дней.

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

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

Сначала проверьте, что сравниваете одно и то же

URL страницы или весь сайт

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

Посмотрите подпись источника полевых данных. Не переносите вывод об origin на отдельную страницу без дополнительной проверки.

Мобильные и настольные устройства

У мобильных посетителей отличаются мощность процессора, размер экрана и качество сети. Сравнивайте mobile с mobile, а desktop с desktop.

Текущая версия и исторический период

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

Одинаковое состояние страницы

Проверьте, что лабораторный запуск видит тот же контент, что посетители. На результат влияют баннер cookie, география, A/B-тест, вход в аккаунт, рекламные параметры, язык, размер экрана и кэш. Быстрая гостевая страница не доказывает скорость авторизованного сценария.

Найдите метрику, которая расходится

Не пытайтесь «улучшить PageSpeed вообще». У LCP, INP и CLS разные причины, поэтому сначала выберите конкретный сигнал.

LCP: основной контент появляется поздно

Если полевой LCP хуже лабораторного, сравните крупный элемент в первом экране на разных шаблонах и размерах экрана. Им может оказаться изображение, заголовок или блок, который в тестовом viewport вообще не был крупнейшим.

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

INP: страница медленно реагирует на действие

INP требует реальных взаимодействий. Обычный Lighthouse-запуск не измеряет его напрямую и использует Total Blocking Time как лабораторный диагностический ориентир, а не равноценную замену.

Воспроизведите действие, на которое жалуются: открытие меню, выбор фильтра, ввод в поиск или добавление товара. Запишите Performance trace в DevTools и ищите длинные задачи, тяжёлые обработчики, повторную отрисовку и сторонние скрипты, занявшие основной поток.

CLS: интерфейс сдвигается позже загрузки

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

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

Порядок диагностики без догадок

  1. Сохраните ссылку на отчёт, точный URL, дату, режим mobile или desktop и источник полевых данных: URL либо origin.
  2. Зафиксируйте, какая метрика расходится и в какую сторону. Не смешивайте LCP, INP и CLS в одну проблему «сайт медленный».
  3. Повторите лабораторный запуск несколько раз. Один удачный результат может скрыть нестабильность ответа сервера или стороннего ресурса.
  4. Воспроизведите вероятно медленный контекст: слабее устройство, ограничьте сеть и CPU, очистите кэш, откройте нужный шаблон и выполните реальное действие.
  5. Если агрегатов CrUX недостаточно, подключите собственный RUM. Собирайте Web Vitals по шаблону страницы и укрупнённым техническим сегментам без персональных данных.
  6. Внесите одно связанное изменение и проверьте его в лаборатории. Полевой эффект оценивайте после накопления новых визитов, сохраняя дату релиза.

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

Как расставить приоритеты

  • Поле плохое, лаборатория хорошая. Доверяйте реальному сигналу и ищите сегмент, которого нет в тесте: устройство, сеть, регион, шаблон или взаимодействие.
  • Поле хорошее, лаборатория плохая. Проверьте пользователей со слабыми устройствами и используйте лабораторию как защиту от регрессий.
  • Оба источника плохие. Начните с воспроизводимой лабораторной причины, затем подтвердите изменение полевыми данными.
  • Полевых данных нет. Это не признак хорошей скорости: для URL или origin могло не хватить наблюдений. Используйте лабораторные тесты и собственный RUM.

Отдельно контролируйте доступность и время ответа критичных URL. Web-Puls помогает заметить отказ или замедление ответа сервера, но не заменяет CrUX, RUM и анализ взаимодействий в браузере.

Что сделать сейчас

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

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

Мониторинг сайтов

Запись нового поддомена уже появилась на авторитетных DNS-серверах, но рекурсивный резолвер всё ещё возвращает NXDOMAIN. Разбираем, как отличить отрицательный кэш от ошибки зоны и что делать безопасно.

Проверьте свой сайт прямо сейчас

Введите адрес сайта: Web-Puls покажет HTTP-код, время ответа и базовую диагностику. Для постоянного контроля можно подключить мониторинг.

Хотите видеть такую историю по своему сайту?

Добавьте сайт в Web-Puls: мы будем проверять доступность, SSL и содержимое страницы.