Що таке PageSpeed насправді

PageSpeed Insights — це діагностичний інструмент від Google. Не KPI. Не рейтинг якості. Не прямий фактор ранжування.

Він показує три речі:

Як швидко завантажується сторінка в лабораторних умовах (емуляція старого телефону)
Які технічні проблеми можуть уповільнювати сайт
Як реальні користувачі відчувають швидкість (Field Data — якщо є достатньо трафіку)

Ключове розуміння: Бал PageSpeed — це не оцінка вашого сайту. Це оцінка того, наскільки він відповідає ідеальним лабораторним умовам на старому пристрої. Реальний світ — інший.

Lab Data vs Field Data — критична різниця

Це найважливіше, що треба розуміти про PageSpeed. Два типи даних — два різних світи:

Lab Data (Лабораторні)	Field Data (Польові)
Емуляція Moto G4 (телефон 2016 року!)	Реальні пристрої ваших користувачів
Повільний 4G (1.6 Mbps)	Різні швидкості: 4G, 5G, WiFi
Фіксовані умови, одна локація	Різні браузери, локації, пристрої
Миттєвий результат	Агреговані дані за 28 днів
Теоретична швидкість	Реальний досвід користувачів (CrUX)

Проблема: Lab Data тестує на Moto G4 з 2016 року через штучно повільний 4G. 90% ваших українських користувачів мають значно кращі пристрої та швидший інтернет. Field Data (якщо є) показує реальну картину.

Коли PageSpeed бреше

PageSpeed занижує оцінку через речі, які насправді корисні для бізнесу:

Third-party скрипти (Analytics, Pixel, чати)

Google Analytics, Facebook Pixel, Hotjar, чат-віджети. Без них — жодної аналітики та лідів. PageSpeed каже "видаліть" — бізнес каже "ні, це наші гроші".

Якісні зображення товарів

Для інтернет-магазину потрібні детальні фото. Стиснуті до "оптимальних" розмірів — виглядають погано. Покупці хочуть zoom, хочуть деталі.

Веб-шрифти та брендинг

Брендові шрифти — частина ідентичності. System fonts (Arial, Times) швидші, але сайт виглядає generic, як з 2005 року.

Інтерактивний JavaScript

Калькулятори, фільтри товарів, пошук в реальному часі, кошик. JavaScript важить, але саме він конвертує відвідувачів у покупців.

Відео та анімації

Hero-відео, product demos, анімовані ілюстрації. Збільшують engagement та конверсію, але "вбивають" бал PageSpeed.

Реальні приклади великих сайтів

Подивимось на PageSpeed Score найуспішніших e-commerce сайтів у світі та Україні:

Сайт	Mobile Score	Річний дохід
Amazon.com	35-45	$575 млрд
eBay.com	40-50	$10 млрд
Rozetka.ua	30-40	$1+ млрд
Prom.ua	25-35	Топ-5 UA
AliExpress	20-30	$40+ млрд

Висновок: Найуспішніші сайти планети мають "погані" бали за PageSpeed. Чому? Бо вони оптимізують для бізнес-метрик (конверсія, revenue), а не для Lighthouse score.

Що реально впливає на бізнес

Замість балів PageSpeed, фокусуйтесь на метриках що реально впливають на гроші:

Perceived Performance (Сприйнята швидкість)

Як швидко сайт ВИГЛЯДАЄ готовим. Skeleton screens, progressive loading, optimistic UI. Користувач бачить контент — йому здається що швидко.

Time to Interactive (TTI)

Коли користувач може клікати, скролити, взаємодіяти. Важливіше за повне завантаження всіх ресурсів.

TTFB (Time to First Byte)

Швидкість відповіді сервера. Залежить від якості хостингу. Це можна і треба оптимізувати.

Функціональність без глюків

Чи працює пошук? Чи додається товар в кошик? Чи проходить оплата? Глюки = втрачені гроші.

Конверсія

Єдина метрика, що реально має значення. Чи купують люди? Чи залишають заявки? Все інше — проміжні показники.

Core Web Vitals — що важливо для Google

Google використовує три метрики як фактори ранжування (але не єдині і не головні!):

LCP (Largest Contentful Paint) — Найважливіший

Коли з'являється найбільший видимий елемент (зазвичай hero image або заголовок).

Добре: менше 2.5 сек | Потребує покращення: 2.5-4 сек | Погано: більше 4 сек

Як покращити: Оптимізувати hero image, швидший хостинг, preload критичних ресурсів, CDN.

INP (Interaction to Next Paint) — Важливий

Як швидко сайт реагує на кліки та тапи користувача. Замінив FID у 2024.

Добре: менше 200 мс | Потребує покращення: 200-500 мс | Погано: більше 500 мс

Як покращити: Оптимізувати JavaScript, розбити довгі таски, використовувати web workers.

CLS (Cumulative Layout Shift) — Помітний

Чи "стрибають" елементи під час завантаження. Дратує користувачів коли кнопка зміщується.

Добре: менше 0.1 | Потребує покращення: 0.1-0.25 | Погано: більше 0.25

Як покращити: Задати розміри зображенням (width/height), зарезервувати місце для реклами та динамічного контенту.

Важливо: Core Web Vitals — це Field Data від реальних користувачів Chrome (CrUX). Вони важливіші за загальний бал PageSpeed. Перевіряйте їх в Google Search Console → Core Web Vitals.

Коли оптимізація шкодить бізнесу

Реальні приклади з моєї практики та індустрії, коли погоня за балами шкодила бізнесу:

Видалили чат-віджет заради +5 балів

Результат: -30% лідів за місяць. Чат генерував конверсії, бо люди мали питання перед покупкою.

Стиснули фото товарів до "оптимальних"

Результат: зросли повернення товарів. Покупці не бачили деталей, отримували не те що очікували.

Видалили Google Analytics для швидкості

Результат: втратили дані для оптимізації рекламних кампаній. ROI реклами впав.

Замінили брендовий шрифт на системний

Результат: сайт втратив впізнаваність та преміальність. Для luxury-бренду це катастрофа.

Inline всі CSS замість файлу

Результат: кожна сторінка важить більше, кеш не працює, повторні візити повільніші.

Правильний баланс: що оптимізувати

Оптимізувати (безпечно)	Не жертвувати (ризиковано)
Хостинг (TTFB) — найбільший ROI	Аналітика (GA4, Pixel, Hotjar)
Формат зображень (WebP, AVIF)	Якість фото товарів
Browser caching	Живий чат / підтримка
CDN для статичних файлів	Брендові шрифти та дизайн
Lazy loading зображень	Інтерактивні функції (фільтри, пошук)
Мініфікація JS/CSS	UX та зручність користування
Gzip/Brotli компресія	Відео та демонстрації продукту

Як покращити швидкість без жертв

Покрокова стратегія що дає результат без шкоди бізнесу:

Оберіть швидкий хостинг — це 50% успіху. Детальний гайд по вибору.
Увімкніть CDN — Cloudflare безкоштовний, дає +20-40% швидкості глобально.
Конвертуйте зображення в WebP — на 25-35% менше без втрати якості.
Налаштуйте кешування — статичні файли мають кешуватись на тижні/місяці.
Lazy load для зображень нижче fold — не вантажте те, що не видно.
Preload критичні ресурси — hero image, основний шрифт, критичний CSS.
Відкладіть некритичний JS — analytics, чати можуть вантажитись після основного контенту.

Детальніше про оптимізацію швидкості читайте в окремій статті.

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

Для більшості сайтів 50-70 на мобільних — нормально. Важливіше щоб Core Web Vitals (LCP, INP, CLS) були в зеленій зоні. Amazon має 35-45 і продає на $575 млрд.

Загальний бал — ні. Core Web Vitals впливають як один з сотень факторів ранжування. Контент, посилання, E-E-A-T значно важливіші. Не жертвуйте функціоналом заради балів.

Mobile тестується на емуляції Moto G4 (2016 рік) з повільним 4G. Це штучно занижує оцінку. Реальні iPhone та Samsung значно швидші. Дивіться Field Data якщо є.

Три кроки з найбільшим ROI: 1) Швидший хостинг з низьким TTFB, 2) Оптимізувати hero image (WebP, правильний розмір, preload), 3) Підключити CDN типу Cloudflare.

Ні, ніколи. Без аналітики ви не знаєте що працює, не можете оптимізувати рекламу, не бачите проблеми. Краще відкласти завантаження скрипта на після основного контенту.

Висновок

PageSpeed Insights — корисний діагностичний інструмент, але не самоціль. 100/100 — це ідеальні лабораторні умови, недосяжні для реальних бізнес-сайтів.

Правильний підхід:

Перевіряйте Core Web Vitals в Search Console — це реальні дані
Оптимізуйте хостинг, кешування, формати — без жертв функціоналу
Вимірюйте конверсію, а не бали Lighthouse
Не видаляйте корисні речі (analytics, чати, якісні фото) заради цифр
Дивіться Field Data, а не Lab Data

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

PageSpeed Insights: міф чи мета?