-
Выборка
URL, устройство и тип данных
-
Причина
Задержанный этап загрузки
-
Правка
Задача конкретному компоненту
-
Приёмка
Повторный тест и основные действия
PageSpeed Insights показывает, как загружается страница, и помогает найти причины задержек. Начинайте с реальных пользовательских данных и конкретного сценария: открыть каталог, выбрать товар, отправить форму. Общий балл полезен для диагностики, но сам по себе не объясняет, почему покупателю неудобно.
Порядок разбора: проверить URL и устройство → отделить реальные данные от теста → найти медленный этап → воспроизвести проблему → изменить одну причину → повторить измерение и проверить основные действия.
Почему в одном отчёте разные результаты
Верхний блок может содержать данные CrUX о реальных посещениях за скользящий период 28 дней. Ниже находится лабораторный запуск Lighthouse в заданных условиях. Это разные измерения: исторические посещения и один диагностический тест. Их назначение объясняет документация PageSpeed Insights.
Проверьте подпись выборки: данные относятся к конкретной странице или всему источнику, то есть сайту. Если статистики для URL недостаточно, нельзя приписывать ему показатели домена. Отсутствие данных CrUX тоже не означает ни быструю, ни медленную работу страницы.
| Что смотрим | Какой вопрос решает | Что нельзя заключать |
|---|---|---|
| Реальные посещения | С какими задержками сталкивается аудитория | Что сегодняшняя правка уже изменила весь исторический период |
| Лабораторный тест | Где искать причину при воспроизведении | Что у каждого покупателя такой же телефон и сеть |
| Данные сайта | Как выглядит общая картина при недостатке данных URL | Что каждая карточка имеет ровно эти показатели |
Мобильный и компьютерный отчёты также не взаимозаменяемы. Запишите выбранный режим, дату, URL и итоговый адрес после редиректов. Для повторных запусков сохраняйте одинаковые условия. Несколько тестов полезнее одного удачного результата, выбранного для отчёта.
Какие метрики читать до списка рекомендаций
- LCP — появление крупнейшего видимого элемента содержимого. Важно найти сам элемент: это может быть фотография, баннер или текст.
- INP — отзывчивость на действия пользователей. Если зависает фильтр после загрузки, одного теста открытия страницы недостаточно.
- CLS — неожиданные сдвиги элементов. Например, кнопка заказа уезжает после загрузки изображения.
- FCP — появление первого содержимого. Ранний логотип ещё не означает, что товар уже виден.
- TBT — блокирующее время в лабораторном измерении. Это подсказка для поиска тяжёлой работы JavaScript, а не замена реального INP.
Оценка Performance объединяет лабораторные метрики с весами. Предупреждение о конкретном файле не вычитается из балла как фиксированный штраф. Метод расчёта опубликован в документации Lighthouse. Поэтому техническое задание «исправить все красные строки» плохо задаёт приоритет.
Учебный разбор: почему медленно появляется фотография
Предположим, в тесте карточки LCP равен 4,2 секунды. Крупнейший элемент — фото товара. Сервер начинает отдавать HTML через 0,8 секунды, а запрос изображения начинается только через 2,4 секунды. Это придуманные измерения для объяснения метода, не аудит конкретного магазина.
Первый вопрос — почему браузер поздно узнаёт адрес фото. Если изображение вставляет скрипт после загрузки товарных данных, уменьшение файла не устранит всё ожидание. Разработчик проверяет исходный HTML, сетевую последовательность и правила загрузки. Для основного изображения первого экрана обычно не нужен отложенный запуск как для далёкой галереи.
После исправления позднего обнаружения измерение повторяют. Если запрос теперь начинается рано, но передача долгая, переходят к размерам и формату файла. Если картинка загружена, но скрыта до окончания скрипта, ищут задержку отрисовки. Такую разбивку LCP на этапы описывает руководство web.dev.
Как расставить приоритеты исправлений
| Наблюдение | Первая проверка | Критерий приёмки |
|---|---|---|
| Долго нет ответа HTML | Сервер, кеш, запросы к данным, перенаправления | Сократилось ожидание документа при сопоставимых условиях |
| Поздно начинается загрузка главного фото | Адрес в HTML, lazy loading, зависимость от JavaScript | Запрос начинается раньше, нужное изображение не заменено неверным |
| Экран прыгает | Размеры изображений, шрифты, вставка баннеров | Основные элементы сохраняют место при загрузке |
| Зависает применение фильтра | Трасса действия, объём обработки, повторные запросы | Фильтр отвечает без длинного зависания и сохраняет выбранные значения |
| Тормозит сторонний виджет | Вклад виджета и возможность более позднего подключения | Ускорение не сломало чат, оплату или фиксацию заявок |
Для взаимодействий используйте отдельный разбор плохого INP. Не отключайте аналитику, согласия и защиту формы только ради красивого теста. Сначала выясните вклад каждого компонента и проверьте более экономный способ его загрузки.
Что передать разработчику
Пример задачи: «На мобильной карточке /catalog/model/ основное фото обнаруживается после ответа скрипта. Приложены отчёт и сетевая запись. Нужно сделать выбранное фото доступным при первоначальном чтении HTML, сохранить переключение вариантов и проверить корзину». Здесь есть наблюдение, место проблемы и границы правки.
После выпуска сравните повторные тесты и работоспособность. Реальные показатели обновляются постепенно по мере накопления посещений. Для своего RUM-мониторинга разделяйте устройства, типы страниц и версии релиза. Не смешивайте ускорение загрузки с обещанием роста позиций или продаж на конкретный процент.
Частые вопросы
Нужно ли добиваться 100 баллов?
Не любой ценой. Сначала устраните задержки, мешающие посетителям, и проверьте коммерческие функции. Если ради балла скрыли товары, сломали форму или убрали нужные данные, задача не решена. Балл используйте вместе с метриками и пользовательскими сценариями.
Почему после исправления балл стал ниже?
Проверьте режим, адрес, условия и несколько запусков. На результат влияет изменчивость измерения. Затем сравните отдельные метрики и сетевую последовательность: общий балл мог измениться из-за другого этапа. Сохранённый отчёт до правки нужен именно для такого сравнения.
Достаточно ли проверить главную?
Нет. Категория, карточка и статья используют разные шаблоны и скрипты. Выберите представителя каждого важного типа, включая тяжёлую страницу. Корзину и личный кабинет дополнительно проверяйте в безопасном тестовом сценарии: публичный URL-анализатор не воспроизводит авторизованный путь покупки.
