Google PageSpeed Insights: як перевірити швидкість сайту та виправити помилки

Google PageSpeed Insights – безкоштовний інструмент Google, який аналізує швидкість і продуктивність вебсторінки на смартфонах та комп’ютерах. Сервіс показує результати реальних користувачів, проводить лабораторне тестування й підказує, що заважає сайту працювати швидше.

За дослідженням Deloitte Digital Milliseconds Make Millions, прискорення мобільного сайту на 0,1 секунди супроводжувалося зростанням конверсії на 8,4% серед досліджених ритейлерів.

У статті розповімо, як користуватися PageSpeed Insights, правильно читати звіт, оцінювати Core Web Vitals і визначати, які технічні проблеми потрібно виправляти насамперед.

Коротко

• Звіт у PSI має 2 частини: field data (реальні користувачі за 28 днів) і lab data (один тестовий прогін Lighthouse). Для рішень про SEO важливіші реальні дані.
• Оцінка 0–100 – це лабораторний показник. Користувач її не бачить, а Google для Core Web Vitals дивиться на LCP, INP і CLS.
• Хороші межі: LCP до 2,5 с, INP до 200 мс, CLS до 0,1 – на 75-му перцентилі завантажень.
• Найчастіші причини повільної сторінки: важкі зображення, блокувальні скрипти, слабка відповідь сервера, зайві сторонні віджети.
• Починайте з LCP-елемента і кешування: це найшвидші правки з видимим результатом.

Зміст

1. Що таке PageSpeed Insights і що він вимірює
2. Як перевірити швидкість сайту в PageSpeed Insights: покроково
3. Метрики Core Web Vitals у звіті
4. Як читати рекомендації: Opportunities і Diagnostics
5. Як виправити типові помилки
6. Реальний приклад: як сайт досяг 32 тисяч користувачів на місяць
7. Чому в PageSpeed Insights оцінка змінюється
8. Альтернативи PageSpeed Insights
9. Чи впливає швидкість на SEO і рейтинг?
10. Чек-лист оптимізації швидкості
11. Типові помилки під час оптимізації
12. Висновок
13. FAQ: поширені запитання

Що таке PageSpeed Insights і що він вимірює

Google PageSpeed Insights (PSI) – онлайн-сервіс на pagespeed.web.dev для аналізу продуктивності окремої вебсторінки. Він оцінює її за чотирма напрямами: продуктивність (Performance), доступність (Accessibility), найкращі практики (Best Practices) та SEO.

Для аналізу швидкості основним є розділ Performance. Він містить лабораторні показники, результати реальних відвідувачів за наявності достатньої статистики та технічні рекомендації.

Інструмент використовує два джерела даних:

• Chrome User Experience Report (CrUX) – агрегована статистика роботи сторінок на пристроях реальних користувачів Chrome.
• Lighthouse – автоматизований тест, який перевіряє сторінку в контрольованих умовах і знаходить можливі причини низької продуктивності.

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

Lab data (Lighthouse) vs Field data (CrUX)

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

Параметр	Lab data	Field data
Джерело	Lighthouse, один тестовий прогін	CrUX, реальні користувачі Chrome
Період	Момент запуску тесту	Ковзне вікно 28 днів
Умови	Емульований пристрій і мережа (для мобільного – середній телефон)	Різні пристрої, мережі, країни
Для чого	Налагодження: можна повторити й порівняти до і після правки	Оцінка реального досвіду й сигнал для Google
Обмеження	Не бачить реальних користувачів, результат коливається	Потрібно достатньо трафіку, оновлюється з затримкою
Що показує	Оцінку 0–100, метрики, рекомендації	LCP, INP, CLS, FCP, TTFB за реальними візитами

Якщо даних для окремого URL недостатньо, PSI може показати статистику для відповідного джерела (origin). Якщо їх немає й там, блок із реальними даними буде порожнім. Так буває на нових і малотрафікових сайтах. Також CrUX збирає статистику для публічно доступних сторінок за наявності достатньої кількості даних від користувачів Chrome.

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

Чому оцінка 0–100 не дорівнює швидкості для користувача

Після тестування Google PageSpeed показує загальну оцінку продуктивності у балах і кольорі:

• 90–100 (зелений) – хороша продуктивність;
• 50–89 (помаранчевий) – потребує покращення;
• 0–49 (червоний) – низька продуктивність.

Це лабораторний результат Lighthouse, розрахований на основі п’яти метрик. За документацією Chrome, їхні частки такі:

Метрика	Вага в оцінці
Total Blocking Time (TBT)	30 %
Largest Contentful Paint (LCP)	25 %
Cumulative Layout Shift (CLS)	25 %
First Contentful Paint (FCP)	10 %
Speed Index (SI)	10 %

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

Тому 95 балів у Lighthouse не означають, що сайт швидко працює для всіх користувачів. І навпаки, оцінка 70 балів не обов’язково свідчить про погані Core Web Vitals за польовими даними.

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

У PageSpeed Insights також періодично оновлюється рушій Lighthouse, а разом із ним можуть змінюватися умови тестування й оцінювання. Тому порівнюйте результати з урахуванням дати, версії інструмента та параметрів перевірки.

Як перевірити швидкість сайту в PageSpeed Insights: покроково

Для перевірки швидкості сайту відкрийте PageSpeed Insights. Знайти сервіс можна за назвою або запитом Google Speed Test, а для аналізу достатньо вказати адресу сторінки.

1. Відкрийте pagespeed.web.dev.
2. Вставте повну адресу сторінки з https. Перевіряйте не лише головну: окремо категорію, картку товару, статтю.
3. Натисніть «Проаналізувати» (Analyze). Тест триває зазвичай до хвилини.
4. Перемикайте вкладки Mobile і Desktop. Починайте з мобільної: там суворіші умови, і саме вона зазвичай визначає проблеми.
5. У верхньому блоці з реальними даними є перемикач «Ця URL-адреса» / «Усе джерело» (This URL / Origin). Перший показує дані однієї сторінки, другий – усього домену.
6. Нижче видно позначку, чи пройдено оцінку Core Web Vitals, і кружечки з оцінками за категоріями.
7. Блок «Діагностика проблем із продуктивністю» містить лабораторні метрики й список рекомендацій. Можна відфільтрувати їх за метрикою (FCP, LCP, TBT, CLS), щоб бачити лише ті, що стосуються конкретного показника.

Назви блоків залежать від мови інтерфейсу й версії сервісу, тому у вас вони можуть відрізнятися.

Перед змінами зробіть таблицю з вихідними значеннями (оцінка, LCP, INP, CLS, TTFB) окремо для мобільної й десктопної версій по 3–5 типових сторінках. Без цього через тиждень не зрозуміти, що саме покращилось. Це база для будь-якої перевірки швидкості сайту. Якщо потрібна комплексна діагностика, команда LuxSite проведе SEO-аудит сайту та визначити пріоритетність виправлень.

Метрики Core Web Vitals у звіті

Core Web Vitals – три ключові показники, за якими Google оцінює швидкість відображення основного контенту, реакцію сторінки на дії користувача та стабільність її елементів. До них належать LCP, INP і CLS. Окремо PageSpeed Insights показує допоміжні метрики, які допомагають з’ясувати причини проблем.

Метрика	Що означає	Добре	Потребує покращення	Погано
LCP (Largest Contentful Paint)	Коли з’явився найбільший видимий елемент: картинка, блок тексту, відео-постер	до 2,5 с	2,5–4 с	понад 4 с
INP (Interaction to Next Paint)	Затримка між кліком, тапом чи натисканням клавіші й наступним кадром	до 200 мс	200–500 мс	понад 500 мс
CLS (Cumulative Layout Shift)	Наскільки елементи «стрибають» під час завантаження	до 0,1	0,1–0,25	понад 0,25
FCP (First Contentful Paint)	Коли з’явився перший контент	до 1,8 с	1,8–3 с	понад 3 с
TTFB (Time to First Byte)	Скільки сервер віддає перший байт	до 0,8 с	0,8–1,8 с	понад 1,8 с
TBT (Total Blocking Time)	Сумарний час блокування основного потоку (лабораторна метрика)	до 200 мс	не визначено	не визначено

Межі за web.dev: LCP до 2,5 с, INP до 200 мс, CLS до 0,1. Вважається, що сторінка проходить оцінку, якщо всі три показники хороші на 75-му перцентилі завантажень, окремо для мобільних і десктопів. FCP і TTFB допомагають аналізувати завантаження, а TBT використовують у лабораторних тестах. Якщо хочете почитати про групу метрик ширше, у нас є окрема стаття про фактори Core Web Vitals.

LCP: що це і як покращити

LCP (Largest Contentful Paint) показує, скільки часу потрібно для відображення найбільшого елемента у видимій частині сторінки. Це може бути головне зображення товару, банер, великий текстовий блок або постер відео. Кандидатами є <img>, зображення всередині SVG, постер <video>, елементи з фоном через CSS url() і блоки з текстом. Хороший показник LCP – до 2,5 секунди.

Корисний прийом: щоб знайти причину затримки, розділіть LCP на 4 складники:

1. TTFB – час очікування першої відповіді сервера.
2. Затримка початку завантаження – час до моменту, коли браузер починає отримувати LCP-ресурс.
3. Тривалість завантаження – час передавання ресурсу.
4. Затримка відображення – проміжок між отриманням ресурсу та його появою на екрані.

За рекомендаціями web.dev, для оптимізованого завантаження LCP орієнтовний розподіл часу такий: TTFB – близько 40%, затримка початку завантаження – менше 10%, передавання ресурсу – близько 40%, затримка відображення – менше 10%. Це орієнтири для діагностики, а не обов’язкові нормативи.

Що робити для покращення LCP:

• Знайдіть LCP-елемент у звіті Lighthouse та перевірте, що саме затримує його появу.
• Якщо це зображення, оптимізуйте його розмір і формат, використовуйте WebP або AVIF.
• Для важливого зображення за потреби задайте fetchpriority=”high” і не використовуйте loading=”lazy”, щоб не відкладати його завантаження.
• Якщо високий TTFB, перевірте серверне кешування, швидкість хостингу та доцільність використання CDN.
• Якщо ресурс уже завантажений, але не відображається, перевірте блокувальні CSS і JavaScript.

Так можна усунути причину затримки, а не оптимізувати все підряд.

INP замінив FID: що це

INP (Interaction to Next Paint) вимірює, наскільки швидко сайт візуально реагує на дії користувача: натискання кнопок, посилань, клавіш або взаємодію з формами. Прокручування, наведення й зум не враховуються. INP оцінює найповільніші взаємодії протягом відвідування сторінки, враховуючи кількість виконаних дій. У березні 2024 року ця метрика замінила FID (First Input Delay) у складі Core Web Vitals.

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

У лабораторії PSI INP не показує, бо для нього потрібні реальні дії користувача. Замість цього дивіться на TBT і на розділи «Зменшіть час виконання JavaScript» та «Мінімізуйте роботу основного потоку».

Типові причини поганого INP: важкі обробники кліків, великі сторонні скрипти, велика кількість елементів на сторінці, синхронні операції в головному потоці.

CLS: стрибки вмісту

CLS (Cumulative Layout Shift) оцінює несподівані зміщення видимих елементів сторінки. Наприклад, користувач хоче натиснути кнопку, але над нею раптово завантажується рекламний банер і зсуває вміст. Унаслідок цього людина може натиснути не туди, куди планувала.

Найчастіші причини високого CLS – зображення без заданих розмірів, рекламні блоки без зарезервованого місця, динамічно доданий контент і зміни розмітки після завантаження шрифтів.

Для зменшення CLS:

• вказуйте width і height або aspect-ratio для зображень і відео;
• резервуйте місце для банерів, віджетів та іншого динамічного контенту;
• не вставляйте нові блоки над уже відображеним вмістом;
• перевіряйте, чи не змінюють завантажені вебшрифти розташування тексту.

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

Як читати рекомендації: Opportunities і Diagnostics

Після вимірювання метрик PageSpeed Insights показує технічні рекомендації. У старіших версіях Lighthouse їх групували в Opportunities («Можливості») і Diagnostics («Діагностика»). У новіших звітах використовується система Performance Insights, а назви окремих перевірок можуть відрізнятися, тому орієнтуйтеся на суть, а не на точну назву рядка. Ось 10 пунктів, які трапляються найчастіше.

Що написано в звіті (за змістом)	Що це значить	Що робити
Усуньте ресурси, що блокують відображення	CSS і JS у <head> не дають браузеру показати сторінку	Критичний CSS вставити inline, решту підключати асинхронно; скрипти з defer
Зображення потрібного розміру й формату	Файл більший, ніж потрібно, або застарілий формат	Стиснути, віддавати WebP/AVIF, робити srcset. Детальніше: як стиснути зображення для сайту
Відкладене завантаження невидимих зображень	Картинки поза першим екраном вантажаться одразу	loading=”lazy” для всього, що нижче першого екрана
Зменшіть невикористаний JavaScript	Завантажується код, який на сторінці не виконується	Прибрати зайві плагіни, розділити бандли, підключати скрипти лише там, де потрібно
Зменшіть невикористаний CSS	Той самий принцип для стилів	Прибрати непотрібні теми й бібліотеки, розділити файли за сторінками
Ефективна політика кешування	Статичні файли не кешуються або кешуються на короткий час	Заголовки Cache-Control або Expires (приклад нижче)
Скоротіть час відповіді сервера	Високий TTFB	Серверний кеш, оптимізація запитів до бази, CDN, апгрейд хостингу
Уникайте надмірного розміру DOM	Занадто багато елементів на сторінці	Спростити верстку, пагінація, віртуалізація довгих списків
Шрифти: показ тексту під час завантаження	Текст невидимий, поки не завантажиться шрифт	font-display: swap, preload критичного шрифту, менше накреслень
Вплив сторонніх скриптів	Чати, віджети, пікселі займають основний потік	Підключати відкладено, прибрати зайві, перевірити внесок кожного

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

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

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

Потрібен розбір вашого звіту? Ми подивимося на LCP-елемент, сервер і скрипти та складемо план правок за пріоритетом. Залиште запит на SEO-просування й технічний аудит.

Як виправити типові помилки

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

Кеш браузера через .htaccess

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

Підходить для серверів Apache з увімкненими модулями mod_expires і mod_headers.

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/avif "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
</IfModule>

<IfModule mod_headers.c>
<FilesMatch "\.(jpg|jpeg|png|webp|avif|svg|woff2)$">
Header set Cache-Control "public, max-age=31536000"
</FilesMatch>
</IfModule>

Ставте довгий термін для CSS і JS лише якщо у назві файлу є версія або хеш (style.a1b2c3.css). Інакше користувачі не побачать оновлень. Для nginx та інших серверів синтаксис інший, тут краще звернутися до адміністратора або до документації сервера.

Стиснення тексту

Багато хостингів уже вмикають стиснення (gzip або Brotli) за замовчуванням. Перевірте заголовок Content-Encoding у відповіді сервера, перш ніж додавати правило.

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json image/svg+xml
</IfModule>

Preload і fetchpriority для LCP-зображення

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

<head>
<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">
</head>

<img src="/img/hero.webp" width="1200" height="600"
alt="Головне фото сторінки" fetchpriority="high">

Якщо браузер знаходить зображення довго, наприклад через CSS або JavaScript, можна додатково застосувати preload. Для шрифту, який використовується в першому екрані, preload виглядає так:

<link rel="preload" as="font" type="font/woff2"
href="/fonts/main.woff2" crossorigin>

Перед завантаженням шрифтів перевірте, чи справді вони потрібні для початкового відображення сторінки. Не варто встановлювати preload для всіх файлів шрифтів одночасно.

Атрибут crossorigin для шрифтів обов’язковий, навіть коли файл лежить на тому ж домені.

Відкладене завантаження: loading=”lazy”

Застосовуйте його до картинок і iframe нижче першого екрана. До LCP-зображення – ніколи.

<img src="/img/product-12.webp" width="600" height="600"
alt="Товар" loading="lazy" decoding="async">

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

WebP та AVIF

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

За допомогою елемента <picture> можна запропонувати браузеру кілька форматів:

<picture>
<source srcset="/img/banner.avif" type="image/avif">
<source srcset="/img/banner.webp" type="image/webp">
<img src="/img/banner.jpg" width="1200" height="500" alt="Банер">
</picture>

Браузер вибере перший формат, який підтримує, а JPEG залишиться запасним варіантом. Для конвертації JPEG у WebP можна використати утиліту cwebp:

cwebp -q 80 banner.jpg -o banner.webp

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

Скрипти й шрифти

JavaScript може затримувати відображення сторінки та реакцію на дії користувача. Якщо скрипт не потрібний для початкового формування HTML, його можна підключити з атрибутом defer:

<script src="/js/app.js" defer></script>
@font-face {
font-family: "Main";
src: url("/fonts/main.woff2") format("woff2");
font-display: swap;
}

Для класичних зовнішніх скриптів defer дозволяє завантажувати файл без блокування розбору HTML і виконувати його після завершення розбору документа. А font-display: swap показує текст запасним шрифтом, поки основний завантажується. Видалення зайвого віджета чи бібліотеки іноді корисніше за мінімізацію CSS і JavaScript.

WordPress

Для WordPress типовими причинами низької продуктивності стають важкі теми, велика кількість плагінів, неоптимізовані зображення та відсутність ефективного кешування.

Що варто зробити:

• Використовуйте кеш-плагін і серверний кеш сторінок. Не ставте одразу кілька плагінів-оптимізаторів: вони конфліктують.
• Сучасні версії WordPress додають loading=”lazy” до зображень у контенті. Перевірте, чи тема не додає його й до головного банера.
• Видаліть невикористані плагіни й теми. Кожен плагін може додавати власні CSS і JS на всі сторінки.
• Стискайте зображення при завантаженні й віддавайте WebP.

Якщо потрібна допомога з оновленнями, кешуванням або виправленням технічних проблем, перегляньте матеріал про технічну підтримку WordPress.

OpenCart

В OpenCart продуктивність часто залежить від кількості товарів, модулів, фільтрів каталогу та складності запитів до бази даних.

• Увімкніть кешування й стиснення на рівні сервера, перевірте налаштування кешу в адмінпанелі та модулях, які ви використовуєте.
• Перевірте велику кількість модулів і банерів на головній: у каталозі їх часто більше, ніж потрібно.
• Оптимізуйте зображення товарів: ресайз під реальні розміри карток і формат WebP.
• Відстежуйте повільні запити до бази: на великих каталогах TTFB росте саме через них. Подробиці в матеріалі про технічну підтримку OpenCart.

Magento

Magento, зокрема Adobe Commerce, використовують для магазинів зі складними каталогами, інтеграціями та значним навантаженням.

• Використовуйте режим production, вбудований повносторінковий кеш і зовнішній кеш (наприклад, Redis і Varnish), якщо інфраструктура це дозволяє.
• У розділі налаштувань розробника перевірте об’єднання та мінімізацію JS і CSS, але тестуйте після кожного перемикача: на складних темах вони можуть ламати верстку.
• Звертайте увагу на сторонні модулі: саме вони додають зайві запити.
• Для складних випадків потрібен розробник.

Реальний приклад: як сайт досяг 32 тисяч користувачів на місяць

Під час SEO-просування сайту виробника металопластикових вікон «Лінія Вікон» команда LuxSite провела технічний аудит, перевірила швидкість завантаження сторінок і роботу сервера. Після першого етапу оптимізації команда щомісяця відстежувала показники PageSpeed Insights, зокрема час завантаження сторінок і відповіді сервера. Це дозволяло контролювати продуктивність після змін у коді та функціоналі сайту.

Результат комплексного SEO-просування: за даними Ahrefs, органічний трафік зріс із 7 до 32 тисяч користувачів на місяць. Роботи тривали понад 12 місяців і включали технічну оптимізацію, оновлення структури та контенту, перелінкування й роботу з посиланнями.

Чому в PageSpeed Insights оцінка скаче і що з цим робити

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

На що ще впливає розкид:

• Сервер. Якщо відповідь сервера нестабільна (спільний хостинг, пікове навантаження), TTFB й LCP коливаються від запуску до запуску.
• Кеш. Прогрів серверного кешу: перший запит може бути повільним, наступні швидкими.
• CDN. Різна географія вузлів дає різний час відповіді залежно від того, звідки йде тест.
• Динамічний контент. Банери, A/B-тести, рекламні блоки змінюють LCP-елемент.
• Сторонні скрипти. Їх час відповіді не залежить від вас.
• Оновлення Lighthouse. Новий рушій може змінити оцінки без жодних змін на сайті.

Що робити: запускайте тест 3–5 разів і беріть медіану, не гонитеся за зеленим кружечком із конкретною цифрою, а дивіться на тренд. Порівнюйте метрики до і після правок в один день і з однієї локації. І головне: для рішень спирайтеся на field-дані та звіт Core Web Vitals у Search Console, де немає розкиду окремих прогонів.

Альтернативи PageSpeed Insights

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

Інструмент	Що дає	Коли використовувати
Lighthouse у Chrome DevTools	Той самий рушій, що в PSI, але запускається локально; можна тестувати сторінки за логіном і локальні збірки	Налагодження перед релізом
Звіт Core Web Vitals у Google Search Console	Реальні дані по групах сторінок сайту: які URL погані й за якою метрикою	Моніторинг усього сайту, пошук проблемних шаблонів
Chrome DevTools: вкладка Performance	Детальний розбір того, що виконує основний потік і коли	Пошук причин незадовільного показника INP і довгих завдань
WebPageTest	Тести з різних локацій і на різних пристроях, водоспадна діаграма запитів	Глибокий аналіз завантаження ресурсів
GTmetrix	Звіти з історією змін і вибором локації тесту	Зручний моніторинг і звіти для клієнтів (умови тарифів перевіряйте на сайті сервісу)
CrUX (дані Chrome UX Report)	Польові дані за походженням і сторінкою, у т. ч. через інструменти на базі CrUX	Порівняння з конкурентами, історія змін

Поєднуйте інструменти: Search Console для моніторингу, PSI для перевірки URL, DevTools – для діагностики.

Якщо потрібно вибрати одну альтернативу Google PageSpeed, орієнтуйтеся на завдання: для розробника корисніший Lighthouse у DevTools, для SEO-фахівця – Search Console, а для поглибленого аналізу мережевих запитів – WebPageTest.

Звичайний Speedtest Google допомагає перевірити швидкість інтернету, але не пояснює, чому сторінка довго завантажується. Для цього використовують PageSpeed Insights, Lighthouse або WebPageTest.

Чи впливає швидкість на SEO і рейтинг?

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

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

Чек-лист оптимізації швидкості

Використовуйте цей чек-лист після первинної діагностики або перед запуском оновленого сайту.

Вимірювання

• Записано вихідні значення PSI (mobile і desktop) для 3–5 типових сторінок
• Перевірено field-дані: за сторінкою й за всім сайтом
• Перевірено звіт Core Web Vitals у Search Console
• Визначено LCP-елемент на ключових шаблонах

Зображення

• Зображення стиснені й мають розмір, потрібний для відображення
• Використовуються WebP або AVIF із запасним форматом
• Вказано width і height (або aspect-ratio)
• loading=”lazy” стоїть на картинках нижче першого екрана
• LCP-зображення не завантажується лінню й має fetchpriority=”high”

Скрипти й стилі

• Скрипти підключено з defer або async
• Критичний CSS винесено, решту завантажено без блокування
• Видалено невикористані плагіни, теми й бібліотеки
• Сторонні віджети (чати, пікселі) завантажуються відкладено або прибрані

Шрифти

• Для шрифтів задано font-display: swap
• Шрифт першого екрана має preload, накреслень не більше, ніж потрібно

Сервер і кеш

• Налаштовано кеш браузера для статики
• Увімкнено стиснення gzip або Brotli
• Увімкнено серверний кеш сторінок, TTFB перевірено
• Для міжнародної або регіональної аудиторії підключено CDN
• Після змін повторно виміряно метрики й порівняно з вихідними

Типові помилки

Найчастіше проблеми виникають через такі рішення:

• Дивляться лише на одну оцінку й ігнорують field-дані.
• Тестують тільки головну, хоча проблема на картках товарів і статтях.
• Ставлять loading=”lazy” на всі зображення, зокрема на LCP.
• Встановлюють кілька кеш-плагінів одночасно.
• Додають довгий кеш для CSS і JS без версіонування файлів.
• Намагаються довести до 100 балів, жертвуючи функціоналом, який потрібен бізнесу.
• Не вказують розміри зображень і отримують стрибки макета.
• Забувають повторно виміряти результат і порівняти з вихідним станом.

Висновок

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

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

Якщо PageSpeed Insights показує низькі результати, а причину складно визначити, наші фахівці допоможуть провести технічний аудит, встановити пріоритетність виправлень і підготувати рекомендації для розробників. Детальніше про наш підхід – на сторінці SEO-просування.

FAQ

Що таке PageSpeed Insights?

Це безкоштовний сервіс Google, що аналізує швидкість сторінки на мобільному й десктопі. Він показує реальні дані користувачів із CrUX за 28 днів, лабораторний тест Lighthouse, метрики LCP, INP, CLS і список рекомендацій. Працює за адресою pagespeed.web.dev, реєстрація не потрібна.

Яка оцінка вважається хорошою?

За Google, 90–100 балів – зелена зона, 50–89 – помаранчева, 0–49 – червона. Проте бал є лабораторним показником. Для SEO важливіше, щоб за реальними даними LCP не перевищував 2,5 с, INP – 200 мс, а CLS – 0,1 на 75-му перцентилі завантажень.

Чому mobile нижче за desktop?

Мобільний тест емулює слабший пристрій і повільнішу мережу, тому скрипти виконуються довше, а ресурси вантажаться повільніше. Крім того, на мобільних часто завантажуються важчі зображення. Розрив між mobile і desktop – нормальна ситуація, тому оптимізацію починають із мобільної версії.

Чим lab відрізняється від field-даних?

Lab data – результати окремого лабораторного тесту сторінки в контрольованих умовах. Field data – агрегована статистика реальних користувачів Chrome за останні 28 днів. Перші використовують для діагностики технічних проблем, другі – для оцінки фактичного користувацького досвіду.

Як пришвидшити сайт на WordPress?

Увімкніть один кеш-плагін і серверний кеш, стискайте зображення й віддавайте WebP, видаліть невикористані плагіни, відкладіть сторонні скрипти, перевірте якість хостингу й TTFB. Не додавайте loading=”lazy” до головного зображення першого екрана. Після кожної зміни повторюйте замір у PSI.

Чи впливає швидкість на позиції?

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