PageSpeed Insights корисний, коли зелена оцінка перестає бути метою. Це діагностичний інтерфейс, що поєднує дані реальних користувачів із контрольованим лабораторним тестом. Завдання — знайти поганий досвід, визначити технічну причину, виправити відповідальний рівень і перевірити результат.
Читайте PageSpeed Insights у правильному порядку
| Блок | Питання | Дія |
|---|---|---|
| Дані користувачів | Чи є проблема в реальних відвідувачів? | Обрати метрику й пристрій |
| Core Web Vitals | Чи проходять LCP, INP і CLS на 75-му перцентилі? | Задати критерій приймання |
| Лабораторний тест | Чи можна відтворити вузьке місце? | Зафіксувати базову лінію |
| Діагностика | Який ресурс, елемент або задача пояснює метрику? | Створити технічне завдання |
Польові та лабораторні дані вимірюють різне
Польовий блок PSI базується на Chrome User Experience Report і описує анонімізований досвід реальних користувачів за ковзний період. Лабораторний блок — запуск Lighthouse у змодельованих умовах. Перший враховує реальні пристрої, мережі, взаємодії та сторонні скрипти; другий дає відтворюваний трейс.
Використовуйте Core Web Vitals як критерії приймання
| Метрика | Добре | Що вимірює | Головне питання |
|---|---|---|---|
| LCP | ≤ 2,5 с | Завантаження головного контенту | Що затримує найбільший елемент? |
| INP | ≤ 200 мс | Чуйність | Яка взаємодія блокує наступний кадр? |
| CLS | ≤ 0,1 | Візуальна стабільність | Який елемент зсувається і чому? |
Оцінюйте 75-й перцентиль окремо для мобільних і десктопних пристроїв. Проходження трьох метрик — ясніший критерій завершення, ніж одна сумарна оцінка.
Діагностуйте LCP за чотирма компонентами затримки
Розкладіть LCP на TTFB, затримку початку завантаження ресурсу, тривалість завантаження та затримку від отримання ресурсу до відмальовування. Високий TTFB веде до сервера й кешу; пізній старт — до виявлення hero-ресурсу; довге завантаження — до розміру й формату; пізній рендер — до CSS, шрифтів, гідратації та main thread.
Діагностуйте INP за конкретною взаємодією
Lighthouse не відтворює весь розподіл реальних дій. Знайдіть повільну взаємодію в польових даних або RUM, а потім повторіть її в DevTools. Відокремте затримку вводу, обробку подій і затримку представлення. Скорочуйте довгі JavaScript-задачі, синхронний layout і конкуренцію сторонніх скриптів.
Діагностуйте CLS за рухомим елементом
Знайдіть нестабільний елемент і тригер. Часті причини: зображення без розмірів, пізні шрифти, банери, реклама без зарезервованого місця та компоненти, вставлені над наявним контентом. Резервуйте простір і не переміщуйте матеріал після початку читання.
Пріоритизуйте за впливом, охопленням і впевненістю
Спочатку виправляйте метрику, яка не проходить у польових даних, зачіпає важливий шаблон або багато посадкових і має доведену технічну причину. Використовуйте краулер сайту для групування шаблонів, аналізатор сторінки для локальної діагностики та процес аналізу crawl stats для серверних проблем.
Проводьте відтворюваний тест
- Запишіть URL, пристрій, місце тесту, час і стан застосунку.
- Зробіть кілька запусків і використовуйте медіану.
- Збережіть метрику, відповідальний елемент і трейс.
- За можливості змінюйте один рівень за раз.
- Повторіть той самий протокол після релізу.
- Стежте за польовими даними, доки вікно не відобразить випуск.
Як швидкість сторінки пов’язана із SEO
Швидкість пов’язана з користувацьким досвідом і сигналами page experience, але не замінює релевантність, корисний контент, доступність для сканування та архітектуру. Google рекомендує добрі Core Web Vitals і цілісний досвід, а не видалення корисних функцій заради ідеального бала.
Включіть продуктивність до чекліста SEO-аудиту, а джерела метрик розподіліть через стек SEO-аналітики.
Поширені помилки PageSpeed
- Оптимізація сумарної оцінки замість проблемної користувацької метрики.
- Тестування лише головної сторінки.
- Висновки за одним запуском.
- Ігнорування cookie-банера, авторизації, реклами й експериментів.
- Закриття завдання одразу після деплою без польової перевірки.
Definition of done для виправлення
Завдання завершене, коли названо метрику й відповідальний елемент, зміну перевірено відтворюваним лабораторним протоколом, критичні функції не зламані, а польову перевірку заплановано. Для шаблонної проблеми додайте вибірку URL і автоматичний performance budget.
Масову проблему документуйте поруч із кейсом діагностики групи URL, а не в розрізнених скриншотах.
Офіційна документація
- Про PageSpeed Insights
- Web Vitals і порогові значення
- Оцінювання продуктивності Lighthouse
- Core Web Vitals і Google Пошук
FAQ
Чи потрібна оцінка 100 для SEO?
Ні. Використовуйте оцінку як лабораторний підсумок, а пріоритет надавайте польовим Core Web Vitals і доведеним причинам.
Чому мобільна й десктопна оцінки різняться?
Вони мають різні припущення про пристрій і мережу; реальні аудиторії також відрізняються обладнанням і поведінкою.
Чому оцінка змінюється між запусками?
Впливають маршрутизація, сервер, сторонні скрипти, реклама, експерименти та нормальна варіативність тесту.
Яким даним довіряти більше?
Поле визначає наявність користувацької проблеми, а лабораторія допомагає відтворити причину та перевірити виправлення.
Коли польові дані покажуть покращення?
CrUX використовує ковзне вікно, тому зміна з’являється поступово. Зафіксуйте дату релізу й період спостереження.