PageSpeed Insights: як читати звіт і що виправляти першим

PageSpeed Insights показує два різні звіти на одній сторінці: реальні дані користувачів Chrome за останні 28 днів і лабораторний тест Lighthouse на емульованому слабкому телефоні. Тому бал 42 у червоному кружечку ще не означає, що сайт повільний для ваших клієнтів, а зелений «пройдено» у верхньому блоці важить більше, ніж будь-яка цифра нижче. Розбираємо, як читати звіт, які рекомендації виправляти першими, хто саме має це робити і чому гонитва за 100 балами зазвичай не окупається.

Два блоки звіту і чому цифри в них різні

Відкриваєте pagespeed.web.dev, вставляєте адресу, чекаєте секунд двадцять. Зверху з'являється блок «Дізнайтеся, з чим стикаються реальні користувачі». Це польові дані з Chrome User Experience Report (CrUX): анонімна статистика від справжніх відвідувачів вашого сайту в Chrome за 28 днів. Google дивиться на 75-й перцентиль, тобто на досвід трьох чвертей користувачів, і за ним виносить вердикт «Core Web Vitals пройдено» або «не пройдено». Саме цей вердикт враховує пошук. Якщо трафіку мало, блок буде порожнім: даних для сторінки або всього домену не вистачає.

Нижче йде лабораторний тест Lighthouse. Сервер Google один раз завантажує сторінку в емуляції середнього Android-телефона на повільному 4G і рахує бал від 0 до 100. Це синтетика: один прогін, одна локація, штучно обмежені процесор і мережа. Цифри між двома блоками розходяться постійно, і це нормально. Польові дані кажуть, що відбувається насправді. Лабораторія показує, де саме вузьке місце, і дає список рекомендацій.

Практичне правило від нас у Query: вердикт по польових даних читаємо як діагноз, лабораторний бал як підказку, з чого починати. Сперечатись із клієнтом про 67 замість 71 у лабораторії немає сенсу, різниця між сусідніми прогонами буває і 10 балів.

Що означає бал від 0 до 100 і чому не треба гнатись за сотнею

Оцінка швидкості сайту в Lighthouse складається з п'яти метрик із різною вагою. Станом на публікацію: Total Blocking Time 30%, Largest Contentful Paint 25%, Cumulative Layout Shift 25%, First Contentful Paint 10%, Speed Index 10%. Зони кольорів: 0-49 червона, 50-89 помаранчева, 90-100 зелена.

Три речі, які варто знати про цей бал. Перше: він нелінійний. Підняти сайт із 30 до 60 зазвичай дешевше, ніж із 85 до 95. Друге: бал рахується для однієї сторінки, а не для сайту. Головна може бути на 90, а картка товару з віджетом відгуків на 35. Третє: Google не використовує лабораторний бал у ранжуванні. Для пошуку значення мають польові Core Web Vitals, і там пороги м'якші, ніж «зелена сотня».

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

П'ять метрик, які ви побачите у звіті

• LCP (Largest Contentful Paint): за скільки з'являється найбільший елемент екрана, зазвичай банер або заголовок. Норма до 2,5 с.
• INP (Interaction to Next Paint): наскільки швидко сторінка реагує на клік чи тап. Норма до 200 мс. Замінила FID у березні 2024 року.
• CLS (Cumulative Layout Shift): наскільки скаче верстка під час завантаження. Норма до 0,1.
• FCP (First Contentful Paint): коли з'являється перший текст або картинка. Норма до 1,8 с.
• TTFB (Time to First Byte): скільки сервер думає перед відповіддю. Норма до 0,8 с. Є лише в польових даних.

Перші три і є Core Web Vitals, за якими виноситься вердикт. Що вони означають фізично і як їх покращувати кожну окремо, ми детально розібрали в статті про Core Web Vitals, тут не повторюємось.

Розділи «Діагностика» і «Можливості»: як розставити пріоритети

Під метриками Lighthouse видає два списки. «Можливості» (Opportunities) мають оцінку економії в секундах: «Використовуйте сучасні формати зображень, економія 3,2 с». «Діагностика» без секунд, там структурні зауваження: «Уникайте великого DOM», «Зменшіть роботу основного потоку». Обидва списки часто налічують 15-20 пунктів, і розробник, якому переслали скріншот, не знає, з чого починати.

Ми сортуємо інакше: спочатку за тим, яку метрику зачіпає рекомендація (LCP і CLS важать по 25%), потім за оцінкою економії, і лише потім за трудомісткістю. Ще важливіше визначити, хто за пункт відповідає, бо половина зауважень взагалі не до розробника.

Топ-8 виправлень за ефектом

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

1. Зображення. Стиснення, WebP або AVIF, srcset під мобільні, lazy loading для всього нижче першого екрана. Часто це мінус половина ваги сторінки й найбільший стрибок LCP.
2. Кеш сторінок і швидкий хостинг. Якщо TTFB понад секунду, жодна фронтенд-оптимізація не врятує. Кешування HTML, свіжа версія PHP, OPcache, а для магазинів Redis.
3. Сторонні скрипти. Кожен віджет чату або піксель це 100-500 мс блокування. Все, що не потрібне для першого екрана, вантажиться з затримкою або після взаємодії.
4. Критичний CSS і відкладений JS. Стилі першого екрана інлайном, решта асинхронно, скрипти з defer.
5. Шрифти. Локальне зберігання замість Google Fonts, формат WOFF2, підмножина символів, font-display: swap. Часто мінус пів секунди FCP.
6. Явні розміри для картинок, відео та рекламних блоків. Прибирає більшість проблем із CLS одним днем роботи.
7. Preload для LCP-елемента. Головний банер із fetchpriority="high" і preconnect до CDN.
8. Чистка невикористаного коду. Найдовше і найдорожче, тому останнє: відключення зайвих плагінів, сплітинг бандлів, заміна важких бібліотек.

Пункти 1, 2 і 6 зазвичай закривають шлях із червоної зони в помаранчеву. Пункти 3-5 дотягують до зеленого вердикту в польових даних. Восьмий пункт для тих, кому потрібні 90+.

Мобільна версія проти десктопу

PSI показує окремі вкладки, і різниця в 30-40 балів між ними звична. Десктоп тестується без обмеження процесора і на швидкій мережі, тому майже завжди зелений. Мобільний тест емулює телефон середнього класу на повільному 4G, і саме він показує реальну картину для більшості української аудиторії: у комерційних нішах мобільний трафік давно перевищує половину. Google також індексує сайти за мобільною версією. Тому дивіться на мобільну вкладку і плануйте роботи по ній. Десктопний бал корисний хіба що для B2B-сайтів, куди ходять з офісних комп'ютерів.

Як перевіряти після правок

Найпоширеніша помилка після оптимізації: один прогін PSI, побачили 48 замість 45, зробили висновок «не допомогло». Робочий порядок такий.

1. До початку робіт зафіксуйте базу: 3-5 прогонів мобільного тесту на 3-4 типових сторінках (головна, категорія, картка, стаття), записати медіану, а не найкращий результат.
2. Після кожного етапу правок повторіть ті самі прогони. Порівнюйте метрики (LCP, TBT, CLS), а не тільки загальний бал.
3. Польові дані оновлюються з затримкою: CrUX збирає 28-денне вікно, тому вердикт «пройдено» зміниться через місяць після правок, не наступного дня.
4. У Search Console є звіт «Основні веб-показники» з групами URL: там видно, скільки сторінок сайту в червоній зоні, а не одна перевірена.
5. Для регулярного контролю поставте моніторинг: PSI має безкоштовний API, і раз на тиждень можна автоматично знімати цифри по ключових сторінках.

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