PageSpeed Insights

PSI використовує два окремі джерела даних. Польові дані надходять із Chrome User Experience Report, який збирає показники реальних користувачів Chrome на мільйонах вебсайтів за кожне 28-денне вікно. Це показує, з чим стикаються ваші реальні відвідувачі прямо зараз. Лабораторні дані надходять із Lighthouse — автоматизованого тесту, який завантажує сторінку в контрольованому браузері з заданими умовами мережі та пристрою. Це дає стабільні, повторювані результати, які можна використовувати для пошуку та виправлення конкретних проблем.

Коли ви вводите URL, PSI запускає Lighthouse і отримує останні дані CrUX, а потім об'єднує їх в один звіт. Він оцінює вашу сторінку за метриками Core Web Vitals: Largest Contentful Paint (як швидко з'являється основний контент), First Input Delay (як швидко сторінка стає інтерактивною) та Cumulative Layout Shift (чи стрибає контент під час завантаження сторінки). Він також перевіряє такі метрики, як Time to First Byte, ресурси, що блокують рендеринг, та оптимізацію зображень. Бали варіюються від 0 до 100: зелений — від 90 і вище, помаранчевий — у діапазоні від 50 до 89, червоний — нижче 50.

Рітейлер вводить URL-адресу сторінки свого товару. PSI показує польові дані LCP на 75-му перцентилі у 3,2 секунди (оцінка «погано») та лабораторний результат Lighthouse у 2,8 секунди. Обидва показники вказують на те, що головне зображення занадто велике. Звіт також показує зміщення макета (layout shift) на 0,14 через банер із відкладеним завантаженням (lazy-loaded), оцінка «потрібно покращити».

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

Оптимізація зображень — це найпоширеніший спосіб отримати результат. Стискайте зображення за допомогою сучасних форматів, таких як WebP або AVIF, встановлюйте явні атрибути ширини та висоти, щоб запобігти зміщенню макета, і використовуйте адаптивні зображення з srcset, щоб мобільні користувачі завантажували менші файли. Використовуйте відкладене завантаження (lazy load) для зображень, які знаходяться нижче першого екрана.

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

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

Перевіряйте PSI після кожної серії змін, щоб підтвердити покращення. Показники реальних користувачів (field data) оновлюються за 28-денним циклом, тому відчутні зміни в реальному досвіді користувачів з'являються не одразу, навіть після випуску коду.

• Стискайте та змінюйте розмір зображень перед завантаженням
• Встановлюйте явні розміри для всіх елементів зображень
• Відкладайте виконання некритичного JavaScript
• Увімкніть заголовки кешування браузера
• Винесіть сторонні скрипти з критичного шляху рендерингу

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

Під показником PSI відображає статус ваших Core Web Vitals: «пройдено» (pass), «потрібні покращення» (needs improvement) або «погано» (poor) як для мобільних пристроїв, так і для настільних комп'ютерів. Це метрики, які Google використовує для ранжування, тому вони важливіші за загальний бал.

Розділ польових даних (field data) показує розподіл за процентилями. Дивіться на 75-й процентиль для мобільних пристроїв, оскільки Google використовує його як еталон для досвіду взаємодії зі сторінкою. Якщо 75-й процентиль знаходиться в межах «добре», ваша сторінка відповідає цій метриці.

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

Щоб відстежити зміни з часом, використовуйте URL у PSI з параметром &str=1, щоб включити історичні дані CrUX, або порівнюйте знімки вручну, зберігаючи звіти. Google Search Console також надає дані Core Web Vitals для всього вашого домену, згруповані за шаблонами URL.

• Погоня за ідеальним балом замість виправлення невдалих показників Core Web Vitals — бал 99 із поганим LCP все одно шкодить ранжуванню

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

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

PSI часто плутають із Lighthouse як із окремим продуктом. Lighthouse працює всередині PSI, але ви також можете запустити його в Chrome DevTools, як модуль Node або через командний рядок. Ці версії можуть давати дещо інші результати, оскільки вони працюють у різних середовищах.

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

Редактор запускає PSI на своїй головній сторінці та бачить показник 62 на мобільних пристроях, при цьому LCP становить 4,8 секунди (оцінка «погано»), а Cumulative Layout Shift — 0,18 (оцінка «погано»). У розділі Opportunities вказано на неоптимізоване головне зображення, що додає 3,2 секунди до часу завантаження, та три таблиці стилів, які блокують рендеринг. У розділі Diagnostics зазначено, що при кожному перегляді сторінки завантажується 420 кілобайт невикористаного CSS. Редактор стискає головне зображення у формат WebP, вбудовує критично важливий CSS для контенту над згином сторінки та відкладає завантаження решти таблиць стилів. Повторний запуск PSI показує, що показник покращився до 81, LCP становить 2,3 секунди (оцінка «потрібні покращення»), а зміщення макета — 0,09 (оцінка «потрібні покращення»). Сторінка все ще не відповідає одному з порогів Core Web Vitals, але трафік із мобільних пристроїв помітно зріс протягом двох тижнів, перш ніж оновилося вікно даних CrUX.

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

• Google Search Central — About PageSpeed Insights
• Google Search Central — Core Web Vitals