PageSpeed Insights: как ускорять сайт, а не улучшать оценку
Обновили старый разбор: теперь начинаем с полевых данных и пользовательского сценария, а лабораторный балл используем как диагностику, не как KPI.
Содержание статьи
PageSpeed Insights — не экзамен с проходным баллом. Это окно в полевые данные и набор подсказок для диагностики. Исправлять нужно задержку в сценарии пользователя, а не красный кружок в отчёте.
Два отчёта на одном экране
В верхней части PageSpeed Insights могут быть полевые данные Chrome UX Report — опыт реальных пользователей за скользящий период. Ниже находится лабораторный прогон Lighthouse на заданных условиях. Эти блоки отвечают на разные вопросы.
Поле показывает, сталкивается ли аудитория с проблемой. Лаборатория помогает повторить её и найти техническую причину. У страницы может быть хороший лабораторный запуск сегодня и слабое поле из-за медленных устройств, отдельных шаблонов или проблемы, которую уже исправили, но период ещё не обновился.
Что измерять кроме оценки
LCP.
Когда появился самый крупный значимый элемент первого экрана.
INP.
Насколько быстро интерфейс визуально отвечает на действия во время визита.
CLS.
Как сильно контент неожиданно сдвигается при загрузке.
Бизнес-событие.
Открылась ли форма, применился ли фильтр, добавился ли товар и ушла ли заявка.
Последний пункт не входит в Core Web Vitals, но именно он объясняет цену проблемы. Медленный калькулятор на странице с высоким намерением важнее тяжёлой иллюстрации в архивной заметке.
Почему балл скачет
Лабораторный прогон зависит от сети, процессора, фоновой нагрузки и сторонних ресурсов. Разница в несколько пунктов между запусками нормальна. Сравнивать нужно не единичный результат, а повторяемый сценарий и конкретные диагностические показатели.
Ещё одна причина — разные URL и шаблоны. Быстрая главная не делает быстрым каталог. Для проверки выбираем типовые страницы: входную, категорию, карточку, статью, форму и личный кабинет. На каждой отмечаем критичное действие.
Приоритеты оптимизации
1. Ответ сервера и цепочка загрузки
Если HTML приходит поздно, остальная оптимизация начинает гонку с опозданием. Проверяем кеш, запросы к базе, географию сервера и редиректы. Затем смотрим, когда браузер узнаёт о главном изображении, шрифте и стилях первого экрана.
2. Изображения по размеру и назначению
Браузеру не нужен исходник 4000 px для карточки шириной 480 px. Используем современные форматы, responsive images и явные размеры. Главное изображение не лениво загружаем, если оно сразу видно; второстепенные — наоборот, откладываем.
3. JavaScript, который мешает ответить
Большой пакет сам по себе не всегда виноват. Важнее, когда и что он делает. Длинная задача в момент нажатия портит INP. Разделяем вычисления, не запускаем виджеты до необходимости, сокращаем повторные рендеры и переносим тяжёлую работу туда, где она не блокирует интерфейс.
4. Стабильная геометрия
Заранее резервируем место под изображения, видео и виджеты. Не вставляем баннер над уже прочитанным текстом. Подбираем загрузку шрифтов так, чтобы замена гарнитуры не перестраивала весь первый экран.
Рабочий протокол
- Выбрать шаблон и критичное действие.
- Посмотреть полевые данные по устройствам и URL.
- Записать лабораторный профиль, а не только итоговый балл.
- Связать задержку с конкретным ресурсом или задачей.
- Исправить одну причину и проверить функцию целиком.
- Сравнить бизнес-события после выпуска.
Оптимизация закончена не тогда, когда отчёт стал зелёным, а когда важное действие работает быстро и предсказуемо на реальном устройстве.
