--- title: "PageSpeed Insights — що показує звіт і що з цим робити" description: "Розбираємо звіт PageSpeed Insights — де реальні відвідувачі, а де симуляція, чому бал стрибає і які пункти списку на нього взагалі не впливають." url: https://apri-code.com/blog/pagespeed-insights-shcho-pokazuye/ language: uk published: 2026-08-18 updated: 2026-08-18 author: "Богдан Кононенко" publisher: Apricode --- # PageSpeed Insights — що показує звіт і що з цим робити Коротка відповідь: на одній сторінці PSI зведено два різні виміри вашого сайту. Зверху — досвід реальних відвідувачів за останні 28 днів. Знизу — одна симуляція завантаження на дешевому телефоні, зроблена щойно. Кольорова цифра, на яку всі дивляться, стосується тільки другого. І половина того, що PSI міряє, взагалі не про швидкість. Хибний висновок із цього звіту роблять зазвичай не через незнання метрик. Просто читають не ту половину. ## Дві половини звіту, які міряють різне ![Поле і лабораторія в одному звіті](https://apri-code.com/api/media/file/psi-halves-uk.svg) Документація описує PSI як звіт про досвід користувача сторінки на мобільних і десктопних пристроях, із рекомендаціями щодо покращення. Слово «досвід» тут не для краси. CLS — це стрибки макета, INP — затримка відгуку на кліки. Це не секундоміри. **Верхній блок — польові дані.** Показники реальних користувачів за попереднє 28-денне вікно збору: FCP, INP, LCP і CLS. Ці числа не залежать від того, коли ви натиснули «Аналізувати». Їх зібрали до вас. **Нижній блок — лабораторія.** Один прогін Lighthouse у заданих умовах: для мобільного це симуляція середнього телефона Moto G4 у мобільній мережі, для десктопа — емуляція з дротовим з'єднанням. Умови однакові для всіх сайтів світу, і в цьому весь сенс. Така перевірка порівнює вас із вами вчорашнім, а не з вашою аудиторією. Google сам розводить два блоки за призначенням. Лабораторні дані корисні для налагодження, бо зібрані в контрольованому середовищі, але можуть не спіймати реальні вузькі місця. Польові фіксують справжній досвід, зате мають вужчий набір метрик. Для власника це означає простий порядок: рішення «чи є проблема» ухвалюють за верхнім блоком, а нижній беруть, щоб зрозуміти, де копати. Пороги й значення самих метрик ми розібрали окремо — [Core Web Vitals простими словами](https://apri-code.com/blog/core-web-vitals-2026/). ## Чому 75-й перцентиль, а не «середній користувач» Над стовпчиками розподілу PSI показує 75-й перцентиль по кожній метриці. Це не середнє і не медіана. Переклад на людську: з чотирьох завантажень беруть третє з кінця, майже найгірше. Число, яке ви бачите в польовому LCP, означає, що 75% відвідувачів побачили контент швидше, а решта чекала довше. Google радить міряти саме цей поріг, окремо для мобільних і десктопних, щоб рекомендоване значення виконувалося для більшості користувачів. Звідси дві речі, які варто прийняти одразу. Перша: ваш власний досвід нічого не доводить. Ви відкриваєте сайт із гарного ноутбука в офісному Wi-Fi і потрапляєте кудись у першу чверть розподілу. Друга: покращення для «більшості» бал не зрушить. Його рухає найповільніший сегмент. У звітах клієнтів це найчастіше мобільний трафік зі старих Android і мереж поза великими містами. ## Що робити, коли польових даних немає взагалі ![Чому верхнього блоку може не бути](https://apri-code.com/api/media/file/psi-crux-uk.svg) Цілком типова картина: верхнього блоку немає, а PSI пише щось про недостатність даних. Це не поломка. Польові дані постачає CrUX, і сторінка потрапляє в його набір за двох умов. Перша — сторінка публічно доступна для індексації за тими ж критеріями, що й у пошукових систем. Друга — достатня популярність, тобто мінімальна кількість відвідувачів. Сторінки й сайти, що не дотягують до порога, у набір просто не входять. Коли по конкретному URL даних бракує, PSI переходить на рівень усього сайту (origin), який охоплює досвід на всіх сторінках разом. Тому картка з даними може бути, але стосуватися вона буде не тієї сторінки, яку ви перевіряли. Тут помиляються найчастіше: святкують зелений LCP на новій посадковій, а це середня температура по домену. Та сама логіка працює у звіті Core Web Vitals у Search Console. URL там групуються за схожим досвідом, група має набрати мінімальний обсяг даних, щоб з'явитися у звіті, а якщо його немає, створюється група вищого рівня, по сайту. Ту саму механіку «читати звіт Google і розуміти, чого в ньому немає» ми розбирали на прикладі [platform properties у Search Console](https://apri-code.com/blog/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% ваших відвідувачів. ## Найдорожча помилка читача звіту ![Екран звіту: бал угорі окремо, довгий список пунктів нижче, між ними порожня смуга](https://apri-code.com/api/media/file/inline-pagespeed-score-vs-list.webp) Під балом ідуть два списки, Opportunities та Diagnostics. Виглядають як план робіт, читаються як план робіт, і саме на них зазвичай кидають бюджет. Документація Lighthouse каже прямо: на бал впливають лише метрики, а не результати Opportunities чи Diagnostics. Там же зроблено уточнення — робота над цими пунктами, найімовірніше, покращить значення метрик, тож зв'язок є, але непрямий. Практично це означає ось що. Пункт із написом «економія стількох-то секунд» — це не секунди у вашому LCP і тим паче не бали. Це оцінка потенціалу для конкретного ресурсу в конкретній симуляції. Закривши десять таких пунктів, можна не зрушити жодну метрику, якщо жоден із них не лежав на критичному шляху відмальовування головного елемента. Порядок дій, який працює: спершу подивіться, яка метрика насправді червона в польових даних, і лише потім шукайте в списках пункти, що впливають саме на неї. Решту ігноруйте без докорів сумління. Що саме гальмує завантаження і як це лікують, розібрано окремо — [швидкість сайту та як прискорити завантаження](https://apri-code.com/blog/shvydkist-saitu-pryskoryty-zavantazhennia/). ## Чому лабораторія і поле законно розходяться Розбіжність між двома блоками не є дефектом інструмента. У неї є три конкретні причини. **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-просування](https://apri-code.com/poslugy/seo/), із фіксацією польових метрик до і після, а не скріншотами балу. ## Часті питання ### Як перевірити швидкість завантаження сайту за допомогою Google? Відкрити PageSpeed Insights, вставити повну адресу конкретної сторінки й переглянути обидві вкладки — Mobile і Desktop. Перевіряйте не лише головну: кожна сторінка міряється окремо. ### Якою має бути швидкість завантаження сайту? Правильніше питати не про «швидкість», а про кожну з метрик і про 75-й перцентиль ваших користувачів. Цільові значення LCP, INP і CLS зібрані в [окремому розборі Core Web Vitals](https://apri-code.com/blog/core-web-vitals-2026/). ### Чому PSI показує різні результати при повторній перевірці? Google пояснює коливання балу змінами базових умов вимірювання. Лабораторний прогін щоразу новий, тому робіть кілька замірів і дивіться на діапазон. ### Чому в звіті немає польових даних? Сторінка не набрала мінімальної кількості відвідувачів для потрапляння в набір CrUX або недоступна для індексації. У такому разі PSI показує дані рівня всього сайту або не показує їх зовсім. ### Чи є аналоги PageSpeed Insights? Так, є інші інструменти вимірювання, зокрема сам Lighthouse у Chrome DevTools і звіт Core Web Vitals у Search Console. Але джерело польових даних у Google-інструментах одне — CrUX, тож розходження між ними частіше стосуються лабораторної частини. ### Чи треба домагатися 100 балів? Ні. Google прямо пише, що «ідеальні» 100 балів надзвичайно важко здобути й на них не розраховують. Робоча мета — зелені польові метрики, а не максимальна цифра. ### Чому в звіті немає FID? FID офіційно виведений із програми Core Web Vitals і замінений на INP 12 березня 2024 року. ### Опрацювали список порад, а бал не змінився. Чому? Бо на бал впливають лише метрики, а не пункти Opportunities та Diagnostics. Якщо закриті пункти не лежали на критичному шляху проблемної метрики, число залишиться тим самим. --- Source: https://apri-code.com/blog/pagespeed-insights-shcho-pokazuye/