PageSpeed Insights полезен, когда зелёная оценка перестаёт быть целью. Это диагностический интерфейс, который соединяет данные реальных пользователей с контролируемым лабораторным тестом. Задача — найти плохой пользовательский опыт, определить техническую причину, исправить ответственный слой и проверить результат.
Читайте PageSpeed Insights в правильном порядке
| Блок | Вопрос | Действие |
|---|---|---|
| Данные пользователей | Есть ли проблема у реальных посетителей? | Выбрать метрику и устройство |
| Core Web Vitals | Проходят ли LCP, INP и CLS на 75-м перцентиле? | Задать критерий приёмки |
| Лабораторный тест | Можно ли воспроизвести узкое место? | Зафиксировать базовую линию |
| Диагностика | Какой ресурс, элемент или задача объясняет метрику? | Создать техническую задачу |
Полевые и лабораторные данные измеряют разное
Полевой блок PSI основан на Chrome User Experience Report и описывает анонимизированный опыт реальных пользователей за скользящий период. Лабораторный блок — запуск Lighthouse в смоделированных условиях. Первый учитывает реальные устройства, сети, взаимодействия и сторонние скрипты; второй даёт воспроизводимый трейс.
Используйте Core Web Vitals как критерии приёмки
| Метрика | Хорошо | Что измеряет | Главный вопрос |
|---|---|---|---|
| LCP | ≤ 2,5 с | Загрузка основного контента | Что задерживает крупнейший элемент? |
| INP | ≤ 200 мс | Отзывчивость | Какое взаимодействие блокирует следующий кадр? |
| CLS | ≤ 0,1 | Визуальная стабильность | Какой элемент сдвигается и почему? |
Оценивайте 75-й перцентиль отдельно для мобильных и десктопных устройств. Прохождение трёх метрик — более ясный критерий завершения, чем погоня за одной суммарной оценкой.
Диагностируйте LCP по четырём компонентам задержки
Разложите LCP на TTFB, задержку начала загрузки ресурса, длительность загрузки и задержку от получения ресурса до отрисовки. Высокий TTFB ведёт к серверу и кэшу; поздний старт — к обнаружению hero-ресурса; долгая загрузка — к размеру и формату; поздняя отрисовка — к CSS, шрифтам, гидратации и main thread.
Диагностируйте INP по конкретному взаимодействию
Lighthouse не воспроизводит всё распределение реальных действий. Найдите медленное взаимодействие в полевых данных или RUM, затем повторите его в DevTools. Отделите задержку ввода, обработку событий и задержку представления. Сокращайте длинные JavaScript-задачи, синхронные layout-операции и конкуренцию сторонних скриптов.
Диагностируйте CLS по движущемуся элементу
Найдите нестабильный элемент и триггер. Частые причины: изображения без размеров, поздние шрифты, баннеры, реклама без зарезервированного места и компоненты, вставленные над существующим контентом. Резервируйте пространство и не перемещайте материал после начала чтения.
Приоритизируйте по влиянию, охвату и уверенности
Сначала исправляйте метрику, которая не проходит в полевых данных, затрагивает важный шаблон или множество посадочных и имеет доказанную техническую причину. Используйте краулер сайта для группировки шаблонов, анализатор страницы для локальной диагностики и процесс анализа crawl stats для серверных проблем.
Проводите воспроизводимый тест
- Запишите URL, устройство, место теста, время и состояние приложения.
- Сделайте несколько запусков и используйте медиану.
- Сохраните метрику, ответственный элемент и трейс.
- По возможности меняйте один слой за раз.
- Повторите тот же протокол после релиза.
- Следите за полевыми данными, пока окно не отразит выпуск.
Как скорость страницы связана с SEO
Скорость связана с пользовательским опытом и сигналами page experience, но не заменяет релевантность, полезный контент, доступность для сканирования и архитектуру. Google рекомендует хорошие Core Web Vitals и целостный опыт, а не удаление полезных функций ради идеального балла.
Включите производительность в чек-лист SEO-аудита, а источники метрик распределите через стек SEO-аналитики.
Распространённые ошибки PageSpeed
- Оптимизация суммарной оценки вместо проблемной пользовательской метрики.
- Тестирование только главной страницы.
- Выводы по одному запуску.
- Игнорирование cookie-баннера, авторизации, рекламы и экспериментов.
- Закрытие задачи сразу после деплоя без полевой проверки.
Definition of done для исправления
Задача завершена, когда названы метрика и ответственный элемент, изменение проверено воспроизводимым лабораторным протоколом, критические функции не сломаны, а полевая проверка запланирована. Для шаблонной проблемы добавьте выборку URL и автоматический performance budget.
Массовую проблему документируйте рядом с кейсом диагностики группы URL, а не в разрозненных скриншотах.
Официальная документация
- О PageSpeed Insights
- Web Vitals и пороговые значения
- Оценка производительности Lighthouse
- Core Web Vitals и Google Поиск
FAQ
Нужна ли оценка 100 для SEO?
Нет. Используйте оценку как лабораторную сводку, а приоритет отдавайте полевым Core Web Vitals и доказанным причинам.
Почему мобильная и десктопная оценки различаются?
У них разные предположения об устройстве и сети; реальные аудитории также отличаются оборудованием и поведением.
Почему оценка меняется между запусками?
Влияют маршрутизация, сервер, сторонние скрипты, реклама, эксперименты и нормальная вариативность теста.
Каким данным доверять больше?
Поле определяет наличие пользовательской проблемы, а лаборатория помогает воспроизвести причину и проверить исправление.
Когда полевые данные покажут улучшение?
CrUX использует скользящее окно, поэтому изменение появляется постепенно. Зафиксируйте дату релиза и период наблюдения.