PageSpeed Insights — що показує звіт і що з цим робити

Коротка відповідь: на одній сторінці PSI зведено два різні виміри вашого сайту. Зверху — досвід реальних відвідувачів за останні 28 днів. Знизу — одна симуляція завантаження на дешевому телефоні, зроблена щойно. Кольорова цифра, на яку всі дивляться, стосується тільки другого. І половина того, що PSI міряє, взагалі не про швидкість.

Хибний висновок із цього звіту роблять зазвичай не через незнання метрик. Просто читають не ту половину.

Дві половини звіту, які міряють різне

Документація описує PSI як звіт про досвід користувача сторінки на мобільних і десктопних пристроях, із рекомендаціями щодо покращення. Слово «досвід» тут не для краси. CLS — це стрибки макета, INP — затримка відгуку на кліки. Це не секундоміри.

Верхній блок — польові дані. Показники реальних користувачів за попереднє 28-денне вікно збору: FCP, INP, LCP і CLS. Ці числа не залежать від того, коли ви натиснули «Аналізувати». Їх зібрали до вас.

Нижній блок — лабораторія. Один прогін Lighthouse у заданих умовах: для мобільного це симуляція середнього телефона Moto G4 у мобільній мережі, для десктопа — емуляція з дротовим з'єднанням. Умови однакові для всіх сайтів світу, і в цьому весь сенс. Така перевірка порівнює вас із вами вчорашнім, а не з вашою аудиторією.

Google сам розводить два блоки за призначенням. Лабораторні дані корисні для налагодження, бо зібрані в контрольованому середовищі, але можуть не спіймати реальні вузькі місця. Польові фіксують справжній досвід, зате мають вужчий набір метрик. Для власника це означає простий порядок: рішення «чи є проблема» ухвалюють за верхнім блоком, а нижній беруть, щоб зрозуміти, де копати. Пороги й значення самих метрик ми розібрали окремо — Core Web Vitals простими словами.

Чому 75-й перцентиль, а не «середній користувач»

Над стовпчиками розподілу PSI показує 75-й перцентиль по кожній метриці. Це не середнє і не медіана.

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

Звідси дві речі, які варто прийняти одразу. Перша: ваш власний досвід нічого не доводить. Ви відкриваєте сайт із гарного ноутбука в офісному Wi-Fi і потрапляєте кудись у першу чверть розподілу. Друга: покращення для «більшості» бал не зрушить. Його рухає найповільніший сегмент. У звітах клієнтів це найчастіше мобільний трафік зі старих Android і мереж поза великими містами.

Що робити, коли польових даних немає взагалі

Цілком типова картина: верхнього блоку немає, а PSI пише щось про недостатність даних. Це не поломка.

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

Коли по конкретному URL даних бракує, PSI переходить на рівень усього сайту (origin), який охоплює досвід на всіх сторінках разом. Тому картка з даними може бути, але стосуватися вона буде не тієї сторінки, яку ви перевіряли. Тут помиляються найчастіше: святкують зелений LCP на новій посадковій, а це середня температура по домену.

Та сама логіка працює у звіті Core Web Vitals у Search Console. URL там групуються за схожим досвідом, група має набрати мінімальний обсяг даних, щоб з'явитися у звіті, а якщо його немає, створюється група вищого рівня, по сайту. Ту саму механіку «читати звіт Google і розуміти, чого в ньому немає» ми розбирали на прикладі platform properties у Search Console.

Без польових даних спирайтеся на лабораторний прогін і власну аналітику. Для нового сайту або сторінки з невеликим трафіком це нормальний стан, а не привід шукати помилку в налаштуваннях.

З чого складається бал і чому він стрибає

Бал Performance — це зважене середнє оцінок метрик. Не сума порад і не кількість зелених галочок.

Таблиця ваг, яку документація Google подає як актуальну, виглядає так: Total Blocking Time — 30%, LCP — 25%, CLS — 25%, First Contentful Paint — 10%, Speed Index — 10%. Одне застереження, і воно чесне: сторінка з цією таблицею підписана як Lighthouse 10, тоді як актуальний реліз інструмента на день перевірки — v13.4.1. Документація може відставати від релізу, тож ваги читайте як орієнтир порядку величин, а не як гарантований на сьогодні розподіл. Для порівняння, у Lighthouse 8 CLS важив 15%, а в наборі ще був Time to Interactive. Шкалу переглядають.

Кольори прості: 0–49 червоний, 50–89 помаранчевий, 90–100 зелений.

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

І окремо про мету. «Ідеальні» 100 балів надзвичайно важко здобути, і на них не розраховують. Це формулювання самого Google, а не наша поблажка. Мета не в цифрі, а в тому, щоб польові метрики трималися в зелених межах для 75% ваших відвідувачів.

Найдорожча помилка читача звіту

Під балом ідуть два списки, Opportunities та Diagnostics. Виглядають як план робіт, читаються як план робіт, і саме на них зазвичай кидають бюджет.

Документація Lighthouse каже прямо: на бал впливають лише метрики, а не результати Opportunities чи Diagnostics. Там же зроблено уточнення — робота над цими пунктами, найімовірніше, покращить значення метрик, тож зв'язок є, але непрямий.

Практично це означає ось що. Пункт із написом «економія стількох-то секунд» — це не секунди у вашому LCP і тим паче не бали. Це оцінка потенціалу для конкретного ресурсу в конкретній симуляції. Закривши десять таких пунктів, можна не зрушити жодну метрику, якщо жоден із них не лежав на критичному шляху відмальовування головного елемента.

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

Чому лабораторія і поле законно розходяться

Розбіжність між двома блоками не є дефектом інструмента. У неї є три конкретні причини.

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

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

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

Тож правильна реакція на розходження — не «якому числу вірити», а «що саме воно мені каже». Поле каже, що відбувається у користувачів. Лабораторія каже, що зламано в коді.

Що звіт вирішує в пошуку, а що ні

Core Web Vitals Google використовує у своїх системах ранжування. Це офіційна позиція. Але поруч із нею стоять три уточнення, які прибирають зайві очікування.

Єдиного сигналу page experience не існує: базові системи ранжування дивляться на набір сигналів, що узгоджуються із загальним досвідом сторінки. Релевантний контент Google показує навіть тоді, коли досвід сторінки посередній. А інші аспекти page experience поза Core Web Vitals прямо не піднімають сайт у видачі, хоча роблять його приємнішим у користуванні.

Ще одна деталь для тих, хто читає старі україномовні матеріали й не розуміє, чому в звіті немає FID. Ця метрика більше не входить до Core Web Vitals і виведена з програми, її замінив INP 12 березня 2024 року. Якщо стаття чи підрядник досі оперують FID, вони описують інструмент минулого.

Короткий чек-лист читання звіту

1. Спершу верхній блок. Немає польових даних — не панікуйте, перевірте, чи це не origin-рівень замість вашого URL.
2. Дивіться на 75-й перцентиль і окремо на мобільну вкладку. Мобільна майже завжди гірша, і саме вона важлива.
3. Бал — індикатор, а не мета. Один прогін нічого не доводить, порівнюйте серії.
4. Списки Opportunities та Diagnostics читайте після того, як визначили проблемну метрику, а не замість цього.
5. Перевіряйте не головну, а сторінки, які приносять гроші: товарні картки, посадкові, кошик.

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

Часті питання