PageSpeed Insights: що це і як читати звіт

PageSpeed Insights - безкоштовний інструмент Google, який перевіряє швидкість сторінки і показує, що саме її гальмує. Працює без реєстрації: вставляєте адресу, за хвилину отримуєте звіт.

Проблема не в тому, як ним користуватися, а в тому, як читати результат. Навколо цього звіту накопичилося більше непорозумінь, ніж навколо будь-якого іншого інструменту Google: підрядникам ставлять задачу «зроби сто балів», через бал сваряться з розробниками, а іноді переробляють сайт, у якого зі швидкістю все гаразд.

Тому далі не стільки інструкція, скільки розбір, що в цьому звіті справді важливо.

1. Як запустити перевірку

Відкрийте pagespeed.web.dev, вставте адресу сторінки і натисніть Analyze. Реєстрація не потрібна, обмежень на кількість перевірок для звичайного використання немає.

Перевіряється конкретна сторінка, а не сайт цілком. Це перше, що зазвичай втрачають з уваги: результат для головної нічого не каже про сторінку товару чи статтю в блозі. У них різна верстка, різна кількість зображень і різні скрипти. Перевіряти треба щонайменше три типи сторінок: головну, категорію і картку товару або статтю.

Угорі є перемикач Mobile і Desktop. За замовчуванням відкривається мобільна версія, і саме на неї треба дивитися: Google оцінює сайти за мобільною версією, та й більшість трафіку в більшості ніш зараз мобільна. Десктопний бал майже завжди вищий і сам собою нічого не доводить.

2. Польові дані: те, що бачать реальні люди

Верхній блок звіту називається «Discover what your real users are experiencing». Це польові дані: реальні вимірювання з браузерів Chrome тих людей, які заходили на ваш сайт за останні 28 днів. Джерело - Chrome User Experience Report, скорочено CrUX.

Це найважливіша частина звіту. Саме ці цифри Google використовує як сигнал ранжування, і саме вони відображають реальність, а не симуляцію.

🔴 Якщо на вашому сайті мало трафіку, цього блоку не буде. Замість нього стоятиме «No Data». Це не поломка і не привід для паніки: у CrUX потрапляють лише сторінки з достатньою кількістю візитів. Для невеликого сайту це нормальний стан, і тоді доводиться орієнтуватися лише на лабораторні дані нижче.

У польових даних три метрики Core Web Vitals. Ось їхні порогові значення за документацією Google.

Метрика	Що міряє	Добре	Погано
LCP	коли відмалювався найбільший видимий елемент	до 2,5 с	понад 4 с
INP	затримка відповіді на дії користувача	до 200 мс	понад 500 мс
CLS	наскільки стрибає верстка під час завантаження	до 0,1	понад 0,25

Важлива деталь, яку майже завжди пропускають: це 75-й перцентиль, а не середнє. Тобто оцінка «добре» означає, що трьом чвертям ваших відвідувачів було добре. Середнє значення тут не використовується взагалі, бо воно ховає найгірші випадки.

Сторінка вважається такою, що пройшла перевірку Core Web Vitals, лише якщо всі три метрики в зеленій зоні одночасно.

І ще одне, що економить час: PageSpeed показує польові дані по одній сторінці. Якщо треба побачити картину по всьому сайту, є звіт «Основні веб-показники» в Google Search Console. Він бере ті самі дані CrUX, але групує сторінки за схожістю, тож одразу видно, що проблема, наприклад, не на головній, а на всіх картках товару. Для роботи це зручніше: ви лагодите шаблон, а не окрему сторінку.

Там же видно, скільки URL у кожній зоні і як це змінювалося останні три місяці. Перевіряти після правок треба саме там: польові дані оновлюються поступово, бо рахуються за 28 днів, і ефект від виправлення видно не раніше ніж за два-три тижні.

3. Лабораторні дані і той самий бал

Нижче йде блок Diagnose performance issues - лабораторні дані. Тут Google не міряє реальних людей, а запускає Lighthouse: одноразову симуляцію завантаження на умовному середньому смартфоні з повільним 4G.

Звідси й береться той самий бал від 0 до 100, через який ламають списи. З ним варто знати три речі.

Бал - це не час завантаження. Це зважена оцінка кількох лабораторних метрик, переведена у сто балів. Сайт із балом 60 не «повільний у два рази» порівняно з сайтом на 90.

Бал стрибає між прогонами. Різниця в 5-10 балів на тій самій сторінці без жодних змін - нормальне явище: симуляція щоразу трохи різна. Робити висновки за одним прогоном не можна, особливо коли порівнюєте «до» і «після».

Сто балів не є метою. Гнатися за останніми десятьма балами зазвичай означає викидати аналітику, чати й піксели реклами, тобто ламати бізнес заради цифри. Розумний орієнтир - зелена зона в польових даних, а лабораторний бал у районі 70-90 на мобільних.

Кольори однакові скрізь: зелений від 90, жовтий від 50 до 89, червоний нижче 50.

4. Рекомендації: що справді варто робити

Нижня частина звіту - список рекомендацій із оцінкою можливої економії часу. Виглядає як список задач, але брати його підряд не варто: частина пунктів дасть десяті частки секунди ціною днів роботи.

Що зазвичай справді впливає.

Зображення. Найчастіша і найдешевша перемога. Формати WebP замість JPEG, стиснення, правильні розміри замість картинки 3000 пікселів, стиснутої засобами браузера до 300, і відкладене завантаження того, що нижче екрана.

Сторонні скрипти. Чати, віджети зворотного дзвінка, піксели, лічильники. Кожен тягне свій код з чужого сервера. Тут корисно чесно перерахувати, що на сайті стоїть, і прибрати те, чим ніхто не користується.

Сервер і кешування. Якщо в лабораторних метриках великий час відповіді сервера, жодна оптимізація картинок не врятує. Це розмова з хостингом, а не з верстальником.

Стрибки верстки. Причина CLS майже завжди одна: у зображень і рекламних блоків не задані розміри, тому браузер підставляє їх після завантаження і контент підстрибує. Лікується атрибутами width і height.

Що зазвичай не варто зусиль: боротьба за останні кілька балів через відкладення дрібного CSS, заміна шрифтів заради сотих секунди, переписування робочих бібліотек.

5. Як користуватися цим у роботі

Практичний порядок, за яким ми дивимося швидкість на проєктах.

Спершу польові дані, якщо вони є. Якщо всі три метрики зелені, зі швидкістю все гаразд незалежно від того, що показує лабораторний бал. Далі є сенс займатися чимось іншим.

Якщо польових даних немає, дивимося лабораторні, але без фанатизму: мета - прибрати очевидні гальма, а не отримати красиву цифру.

Перевіряємо кілька типів сторінок, а не лише головну. Найчастіше найгірший результат саме в каталозі чи картці товару, тобто там, де живуть гроші.

Порівнюємо «до» і «після» щонайменше за трьома прогонами, щоб не сплутати реальне покращення з розкидом симуляції.

Поширені помилки

Висновок за одним прогоном. Прогнали, побачили 62, наступного дня 71, вирішили, що щось покращилось. Не покращилось нічого: це розкид симуляції. Будь-яке порівняння «до» і «після» робиться щонайменше на трьох прогонах, і краще в один і той самий час доби.

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

Порівнюють себе з конкурентом за балом. У конкурента 90, у вас 55, отже треба терміново все переробляти. Насправді у вас може бути інший набір функцій: онлайн-оплата, чат, калькулятор, відгуки. Порівнювати має сенс польові дані, а не лабораторний бал.

Оптимізували, а бал не змінився. Найчастіша причина - правки зробили на стороні верстки, а вузьке місце в часі відповіді сервера. Перевіряється за метрикою TTFB: якщо вона висока, починати треба з хостингу й кешування.

Прибрали важливе заради цифри. Знято чат, знято аналітику, відкладено завантаження шрифтів так, що текст стрибає. Бал виріс, заявок стало менше. Швидкість потрібна заради користувача й конверсії, а не навпаки.

Чекають миттєвого ефекту в польових даних. Після виправлення лабораторний бал зміниться одразу, а польові дані - через два-три тижні, бо рахуються за 28-денним вікном. Це не означає, що правка не спрацювала.

І окремо: швидкість - це фактор ранжування, але слабкий. Він працює як гігієна: дуже повільний сайт втрачає позиції й конверсію, але прискорення з 70 до 85 балів саме собою в топ не виведе. Якщо сторінка не ранжується, причина майже завжди в контенті, посиланнях або технічних помилках індексації, а не в тому, що бал не сто.