PageSpeed Insights полезен не тем, что показывает число от 0 до 100, а тем, что разделяет две разные задачи: оценку реального опыта пользователей и техническую диагностику конкретной загрузки страницы. Если смотреть только на зелёный или красный балл Performance, можно потратить время на улучшения, которые почти не меняют пользовательский опыт.
Сначала определите, какие данные вы сейчас читаете
В верхней части отчёта PageSpeed Insights могут быть полевые данные Chrome User Experience Report — CrUX. Это агрегированная статистика реальных пользователей за предыдущие 28 дней. Для Core Web Vitals ключевыми остаются три метрики: LCP, INP и CLS.
LCP показывает, насколько быстро появляется основной крупный элемент страницы; хорошим считается значение до 2,5 секунды. INP оценивает отзывчивость после взаимодействий пользователя; целевой уровень — до 200 мс. CLS характеризует неожиданные смещения макета; хорошее значение — не выше 0,1. Оценка строится по 75-му процентилю: хороший результат должен обеспечиваться для большинства реальных посещений, а не только для удачного единичного запуска.
Ниже находится лабораторная диагностика Lighthouse. Она выполняется в контролируемых условиях и нужна прежде всего для поиска причин: тяжёлого JavaScript, блокирующих ресурсов, поздней загрузки LCP-элемента, смещений макета и других проблем.
Поэтому первая развилка проста: CrUX отвечает на вопрос «что испытывают реальные пользователи», а Lighthouse — «что в конкретном тесте могло привести к плохому результату».
Почему PageSpeed Insights показывает разные результаты при повторном тесте
Лабораторный результат не обязан повторяться один в один. На него влияют маршрут сети, серверный ответ, сторонние скрипты, рекламные блоки, A/B-тесты и другие условия. Даже без изменения кода общий Performance score может немного колебаться.
Из этого следует практическое правило: не принимайте решение по одному прогону. Если после изменения оценка стала 74 вместо 68, это ещё не доказательство улучшения. Сравните несколько запусков в одинаковом режиме, посмотрите на отдельные метрики и только потом делайте вывод.
Особенно осторожно сравнивайте мобильный и десктопный режимы. У них разные условия эмуляции и оценки. Высокий desktop score не означает, что мобильная версия уже достаточно быстрая.
Как читать Performance score и не оптимизировать ради цифры
Performance score — агрегированный показатель Lighthouse. В него входят отдельные лабораторные метрики, а блоки рекомендаций и диагностики напрямую в балл не складываются. Они помогают найти причины, устранение которых уже может улучшить метрики и итоговую оценку.
Полезнее смотреть не на вопрос «как получить 100», а на три вопроса:
- Какая метрика действительно просела?
- Какой элемент или ресурс связан с этой метрикой?
- Изменился ли результат после исправления в нескольких повторных тестах и затем в полевых данных?
Google прямо указывает, что идеальная оценка 100 не является обязательной целью. Для SEO тем более нельзя трактовать 100/100 как гарантию роста позиций: Core Web Vitals используются системами ранжирования, но хорошая производительность — лишь часть общего качества страницы.
Что исправлять в зависимости от проблемной метрики
Если хуже всего LCP, сначала найдите сам LCP-элемент. Часто это hero-изображение, крупный заголовочный блок или другой заметный элемент первого экрана. Затем проверьте время ответа сервера, приоритет загрузки ресурса, формат и размер изображения, наличие лишней ленивой загрузки для первого экрана и блокирующие CSS или JavaScript.
Если проблема связана с отзывчивостью, ориентируйтесь не только на лабораторный Total Blocking Time, но и на полевой INP. TBT полезен как диагностический лабораторный индикатор нагрузки главного потока, но он не заменяет реальный INP. Ищите длинные задачи JavaScript, тяжёлые обработчики событий, чрезмерную работу клиентского кода и сторонние скрипты.
Для CLS ищите элементы, которые появляются без заранее зарезервированного места: изображения без размеров, рекламные вставки, поздние баннеры, веб-шрифты и динамические блоки над уже отображённым контентом. Исправление должно убирать само смещение, а не просто маскировать его.
Как работать с рекомендациями и диагностикой
Не каждая рекомендация PSI одинаково важна. Сначала связывайте её с ухудшенной метрикой. Если LCP уже хороший, уменьшение нескольких килобайт второстепенного JavaScript может дать красивую строку в отчёте, но не быть приоритетом бизнеса.
Удобно разделить задачи на три уровня:
- критические — напрямую влияют на плохую Core Web Vital или заметно ухудшают первый экран;
- значимые — уменьшают нагрузку и повышают устойчивость страницы, но эффект нужно измерять;
- косметические — улучшают лабораторный отчёт, однако почти не меняют пользовательский сценарий.
Такой порядок особенно важен на WordPress-сайтах, где легко начать «лечить» отчёт десятком плагинов оптимизации и получить новые конфликты. Сначала найдите причину, затем внесите одно контролируемое изменение и повторите измерение.
Практический сценарий: мобильный LCP плохой, а desktop почти зелёный
Предположим, мобильный PageSpeed Insights показывает слабый LCP, а на компьютере страница выглядит быстрой. В полевых данных тоже видно, что LCP не проходит хороший порог.
Сначала определите LCP-элемент. Если им оказалась обложка первого экрана, проверьте, не загружается ли она через lazy-load, не приходит ли слишком большой файл и не задерживается ли запрос из-за CSS или JavaScript. После исправления выполните несколько мобильных лабораторных тестов и сравните именно LCP, а не только общий балл.
Если лабораторный LCP заметно улучшился, это подтверждает направление работы, но не означает, что CrUX изменится сразу. Полевой показатель агрегируется за скользящее 28-дневное окно, поэтому эффект проявляется постепенно по мере накопления новых посещений.
В этой точке полезно отделять оптимизацию загрузки от других технических задач. Например, скорость обхода поисковым роботом — отдельная тема и не должна подменять анализ пользовательской производительности.
Когда полевые данные важнее лабораторного теста
Если CrUX показывает плохой опыт пользователей, а Lighthouse при повторных запусках выглядит хорошо, приоритет остаётся за полевым сигналом: реальная аудитория сталкивается с условиями, которые лаборатория не воспроизводит. Это могут быть слабые устройства, нестабильная сеть, география, авторизованные сценарии, реклама или сторонние скрипты.
Обратная ситуация тоже нормальна: Lighthouse может быть красным, а CrUX — хорошим. Тогда лабораторный тест нужно использовать как предупреждение и источник гипотез, но не объявлять страницу «медленной для всех».
Для более глубокого разбора самого инструмента можно свериться с отдельным материалом PageSpeed Insights, но при исправлении конкретной страницы всегда возвращайтесь к её метрикам и реальным условиям.
Как подтвердить, что исправление действительно сработало
После каждого изменения сохраняйте исходные значения, повторяйте лабораторный тест несколько раз в сопоставимых условиях и проверяйте конкретную метрику, ради которой выполнялась работа. Не объединяйте одновременно десять оптимизаций: иначе вы не поймёте, что именно дало эффект или вызвало регрессию.
Для быстрой технической проверки Lighthouse достаточно. Для итоговой оценки пользовательского эффекта смотрите CrUX и отчёт Core Web Vitals в Search Console после накопления данных. Если нужная метрика улучшилась у реальных пользователей, а страница при этом не получила функциональных ошибок, исправление можно считать подтверждённым.
FAQ
Почему хороший балл PageSpeed ещё не означает, что проблема решена
Для реального пользовательского опыта важнее полевые LCP, INP и CLS, а Performance score Lighthouse следует использовать как лабораторный диагностический показатель. Google отдельно предупреждает, что стремление к идеальному баллу только ради SEO не является самоцелью и не гарантирует высоких позиций.
Для URL может не хватать репрезентативных данных CrUX, особенно у новой или редко посещаемой страницы. В таком случае PageSpeed Insights может перейти к данным уровня origin — всего протокола, хоста и порта сайта; если данных недостаточно и там, полевой блок не отображается.
CrUX использует скользящее окно предыдущих 28 дней, поэтому изменение не появляется мгновенно и не требует ожидания ровно 28 суток. Новые посещения постепенно заменяют старые в выборке, и показатель меняется по мере накопления свежих данных.
Lighthouse тестирует мобильный и десктопный режимы в разных условиях, а реальные пользователи также отличаются устройствами и качеством соединения. Поэтому результаты нужно анализировать раздельно и не считать хороший desktop score доказательством нормальной мобильной производительности.
Рейтинг статьи
Материал был полезен?
Оценка помогает понимать, какие материалы стоит обновлять и расширять.
