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, але з пройденими порогами всіх трьох метрик для реальних відвідувачів вигравaє більше, ніж сайт, доведений до 100 ціною урізаного функціоналу.