PageSpeed Insights показывает один сводный балл от 0 до 100 и десятки отдельных строк с диагностикой, но большинство администраторов читают только число наверху. Разберём, что стоит за этим числом, какие цифры в отчёте можно доверять, а какие — ориентировочная оценка одного замера.
Из чего складывается цифра 0-100
Итоговый балл Lighthouse (именно он показан крупным числом в PageSpeed Insights) — это не сырой набор метрик, а взвешенная сумма шести измерений, где у части метрик вес заметно выше: Total Blocking Time весит больше всех.
| Метрика | Вес в итоговой оценке |
|---|---|
| First Contentful Paint (FCP) | 10% |
| Speed Index (SI) | 10% |
| Largest Contentful Paint (LCP) | 25% |
| Total Blocking Time (TBT) | 30% |
| Cumulative Layout Shift (CLS) | 25% |
Сами границы цвета известны заранее: от 0 до 49 баллов — красная зона, от 50 до 89 — оранжевая, от 90 до 100 — зелёная. Из таблицы видно, что погоня за одной метрикой без улучшения TBT почти не сдвинет итоговый балл — вес этой метрики больше суммы весов FCP и SI вместе.
Зачем нужны Lab Data и Field Data
Верхний блок отчёта — Lab Data, одно измерение в эмулированных условиях (симулированное мобильное устройство среднего класса и замедленная сеть); он стабильно воспроизводится, но не отражает разброс реальных посетителей.
Ниже, если у сайта достаточно трафика, попавшего в Chrome User Experience Report, появляется блок с реальными данными посетителей за последние 28 дней — именно этот блок решает, пройдёт ли сайт оценку Core Web Vitals в Google Search Console; у сайтов с низким трафиком этого блока нет вовсе, и ориентироваться приходится только на Lab Data.
Как читать список рекомендаций
Ниже оценки идёт список диагностик с оценкой потенциальной экономии времени — она не складывается арифметически, потому что часть улучшений перекрывает друг друга, но порядок в списке примерно соответствует значимости находки.
Eliminate render-blocking resources — Est savings of 0.4 sЦифра экономии получена на одном симулированном прогоне и показывает верхнюю границу эффекта этой конкретной правки в лабораторных условиях — она не гарантирует такое же снижение Field Data у реальных посетителей, потому что их устройства и сети отличаются от эмуляции.
На что смотреть первым
Список диагностик стоит читать не сверху вниз по порядку в отчёте, а по сумме факторов:
- Начинать с пункта с самой крупной оценкой экономии — он даёт больше шансов сдвинуть итоговый балл за одну правку.
- Проверить время ответа сервера (TTFB) раньше правок на стороне фронтенда — медленный TTFB тянет вниз LCP независимо от оптимизации картинок и скриптов; сжатие ответов разобрано в статье про Gzip и Brotli в Nginx.
- Задавать атрибуты width и height у изображений, даже если сами файлы уже оптимизированы — это убирает сдвиг макета независимо от веса картинки.
- Не гнаться за цифрой 100, вручную правя отдельные директивы — большую часть пунктов из списка закрывает связка кэша, сжатия и современных форматов изображений, разобранная в статье об ускорении WordPress.
- Перепроверять отчёт после каждой правки отдельно, а не после пакета из десяти изменений сразу — иначе непонятно, какая именно правка дала эффект, а какая не повлияла вовсе.
Отдельно от этого списка в отчёте есть раздел Passed audits — то, что уже сделано правильно; его смысл не чинить, а не трогать лишний раз при следующей правке темы или плагина.
Что отчёт не покажет
PageSpeed Insights проверяет одну страницу в один момент времени — он не покажет, что сервер стабильно отвечает медленно по ночам из-за резервного копирования или что сайт недоступен несколько минут не в момент замера.
Для этого нужен отдельный постоянный контроль доступности и времени ответа — например, настроенный, как в статье про мониторинг сайта: UptimeRobot, Zabbix и системные алерты; отчёт PageSpeed дополняет такой контроль, но не заменяет его.
Частые вопросы
Почему оценка на телефоне и на компьютере отличается?
Мобильная оценка использует куда более жёсткое ограничение CPU и сети, чем десктопная, поэтому один и тот же сайт закономерно получает разные баллы на двух вкладках отчёта — сама по себе разница не говорит о скрытой проблеме только на одной из платформ.
Можно ли по этому отчёту судить о позициях сайта в поиске?
Нет, оценка PageSpeed отражает только метрики Core Web Vitals и общую скорость, но не весь набор факторов ранжирования — высокий балл не гарантирует высокую позицию, а низкий не объясняет падение позиций сам по себе, если другие факторы (контент, ссылки, релевантность) не изменились.
Стоит ли переделывать сайт только чтобы получить 100 баллов?
Нет, итоговая цифра — ориентир, а не цель сама по себе: пользовательский опыт определяют реальные Core Web Vitals из Field Data, и сайт с баллом заметно ниже 100, но с пройденными порогами всех трёх метрик для реальных посетителей выигрывает больше, чем сайт, доведённый до 100 ценой урезанного функционала.