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 это не оценка в дневнике, а список подсказок, и читать его надо сверху, с полевых данных, а не с цвета кружка.