PageSpeed Insights: как читать отчёт и выбирать исправления
PageSpeed Insights полезен, когда по его отчёту можно понять причину задержки и поставить проверяемую задачу разработчику. Начинайте с адреса страницы, типа устройства и данных реальных посетителей. Затем изучайте лабораторные метрики и рекомендации, связанные с обнаруженной проблемой. Цветной балл помогает ориентироваться, но не заменяет такой разбор.
Это руководство объясняет, как пользоваться Google PageSpeed Insights владельцу сайта, маркетологу и вебмастеру: читать два разных блока данных, находить значимые замечания, выбирать очерёдность исправлений и принимать результат. Отдельно разобраны ограничения инструмента и его API.
Как запустить PageSpeed Insights и проверить нужную страницу
Откройте PageSpeed Insights, вставьте полный адрес публичной страницы и запустите анализ. Проверяйте конкретную посадочную, категорию или карточку: результат главной не описывает автоматически все шаблоны сайта. Убедитесь, что выбран нужный вариант домена и протокола.
Сначала посмотрите, что действительно открыл сервис
После завершения анализа проверьте адрес и изображение страницы в лабораторном блоке. На скриншоте должно быть ожидаемое содержимое. Если вместо каталога видна ошибка, заглушка или проверка доступа, такой запуск нельзя принимать за оценку каталога. Быстрый показ постороннего экрана не подтверждает хорошую работу целевой страницы.
При переадресации уточните конечный URL. Например, мобильный посетитель может попасть на другой маршрут, а ссылка со старым доменом — пройти несколько переходов. Эти детали нужны разработчику для воспроизведения результата, особенно когда обычный браузер показывает другую картину.
Зафиксируйте контекст отчёта
Сохраните дату, адрес, выбранную вкладку устройства и версию сайта. Если сравниваете результаты с прошлой проверкой, убедитесь, что содержимое осталось сопоставимым. Новый баннер, другая подборка товаров или изменённая форма могут влиять на загрузку независимо от технических правок.
Публичный сервис предназначен для доступных ему страниц. Для кабинета после входа нужен отдельный согласованный сценарий диагностики. Не передавайте в поле анализа ссылку с токеном доступа, персональными сведениями или одноразовым секретом.
Данные реальных пользователей: что находится в верхнем блоке
Блок об опыте реальных пользователей получает сведения из Chrome UX Report, или CrUX. Это накопленные наблюдения подходящих посещений, а не результат только что запущенного теста. Официальное руководство по CrUX в PageSpeed Insights объясняет расположение полевых данных и их отличие от диагностики Lighthouse ниже.
Отдельный URL и весь origin — разные объекты
Посмотрите, к чему относятся показатели: к проверяемой странице или к origin — сочетанию схемы, имени хоста и порта. Если у конкретного адреса недостаточно наблюдений, может отображаться агрегат origin. Его нельзя подписывать как точный результат одной карточки: в общий набор входят другие страницы и сценарии.
Сравнивая мобильные устройства и компьютеры, сохраняйте это разделение. Хорошие показатели одной группы не компенсируют проблемы другой. Для задачи важно, где возникает отклонение и относится ли выбранная группа к вашей аудитории.
Период сбора и 75-й перцентиль
Полевые значения описывают предшествующий период в 28 дней. Значение на 75-м перцентиле означает, что примерно 75% соответствующих наблюдений не превышают его. Это не среднее время и не обещание одинакового опыта для каждого посетителя. Полосы распределения показывают доли хороших, промежуточных и плохих результатов.
После обновления сайта в накопленных данных некоторое время остаются посещения старой версии. Поэтому изменение лабораторного результата может появиться раньше заметного изменения полевого агрегата. Сопоставляйте даты, а не объявляйте работу неудачной по неизменившемуся верхнему блоку сразу после выпуска.
Что означает оценка Core Web Vitals
При достаточных данных оценка учитывает LCP, INP и CLS на 75-м перцентиле. Есть важная оговорка: если недостаточно INP, PSI может показать успешное прохождение при хороших LCP и CLS. Если не хватает LCP или CLS, оценить агрегат нельзя. Эти условия приведены в описании PageSpeed Insights.
Сообщение об отсутствии данных не означает нулевую скорость. Включение в CrUX зависит от критериев доступности и достаточности наблюдений. Для новой или редко посещаемой страницы продолжайте лабораторную диагностику и наблюдение за настоящими визитами.
Лабораторный блок: один запуск в заданном окружении
Раздел диагностики создаётся Lighthouse. Он открывает страницу в моделируемых условиях, собирает метрики и на их основе формирует отчёт. Такой запуск удобен для поиска конкретных задержек, но не воспроизводит все устройства, соединения и действия вашей аудитории.
Мобильная и настольная вкладки
Проверяйте обе вкладки отдельно. Они используют разные условия, поэтому их баллы нельзя усреднять в «общую скорость сайта». Если основной поток заявок приходит с телефона, мобильный сценарий заслуживает самостоятельной проверки, даже когда настольный результат хороший.
Смотрите сведения об окружении: тип устройства, параметры моделирования и момент запуска. Регион инфраструктуры Google может различаться; PSI не предоставляет выбор конкретного российского города. Мобильная эмуляция не равна тесту через сеть определённого оператора.
Почему показатели поля и лаборатории расходятся
У посетителя могли быть тёплый кеш, другое содержимое, более слабое устройство или взаимодействия после загрузки. Лабораторный запуск показывает выбранный сценарий в конкретный момент. В разборе различий полевых и лабораторных данных эти причины рассматриваются отдельно.
Сохраняйте оба результата. Если полевая оценка плохая, а лаборатория выглядит хорошо, задача состоит в воспроизведении недостающего сценария. Если свежий лабораторный тест ухудшился после обновления, это повод проверить новую версию, даже когда накопленные данные ещё спокойные.
Что означают баллы Performance, Accessibility, Best Practices и SEO
В отчёте показаны отдельные категории. Performance характеризует измеряемую производительность, Accessibility — автоматические проверки доступности, Best Practices — предусмотренные проверки веб-практик, SEO — набор технических условий обнаружения и понимания страницы. Они не являются четырьмя вариантами одной оценки скорости.
Performance не равен проценту быстродействия
Баллы производительности рассчитываются как взвешенная комбинация оценок метрик. Веса и преобразование времени в баллы описаны в документации Lighthouse. Результат 80 не означает, что сайт работает на 80% возможной скорости; прибавка десяти баллов не равна ускорению на десять процентов.
Диапазон 90–100 считается хорошим, 50–89 требует улучшения, 0–49 — плохим. При этом сами диагностические замечания не добавляют штрафные баллы каждое по отдельности. Исправление рекомендации влияет на Performance через изменение метрик. Поэтому количество предупреждений не позволяет вычислить будущий результат.
Другие категории требуют своей проверки
Высокий Accessibility не отменяет ручную проверку. Например, необходимо убедиться, что форма понятна человеку, последовательность фокуса удобна, а важные действия доступны с клавиатуры. Описание оценки доступности Lighthouse отдельно указывает, что ручные проверки не включаются в её числовой расчёт.
Сто баллов SEO не являются полным SEO-аудитом или прогнозом позиций. Инструмент не оценивает соответствие предложения спросу, полноту текста и всю конкуренцию по запросу. Google также поясняет, что хорошие Core Web Vitals сами по себе не гарантируют верхних позиций в поиске.
Какие показатели PageSpeed Insights разбирать в первую очередь
Связывайте показатель с тем, что замечает посетитель. Основное содержимое может появляться поздно, интерфейс — сдвигаться, а действия — получать задержанную обратную связь. Для каждой проблемы нужен свой след в отчёте и свой способ воспроизведения.
| Показатель | Практический смысл | Как использовать |
|---|---|---|
| LCP | Появление крупнейшего подходящего элемента в видимой области | Найти элемент и этап, который задерживает его показ |
| INP | Отзывчивость на взаимодействия в полевых данных | Исследовать проблемные действия, а не только старт страницы |
| CLS | Неожиданные сдвиги интерфейса | Найти момент движения и вызвавшее его изменение |
| FCP | Первое появление содержимого | Отделить долгий пустой экран от позднего основного блока |
| TBT | Блокировки основного потока в лабораторном интервале | Проверить тяжёлую работу при загрузке |
| Speed Index | Темп визуального заполнения страницы в лаборатории | Сопоставить число с последовательностью отображения |
Для Core Web Vitals хорошие ориентиры на 75-м перцентиле — LCP не более 2,5 секунды, INP не более 200 миллисекунд и CLS не более 0,1. CLS не измеряется в секундах. Остальные показатели помогают диагностике, но не заменяют эти три метрики.
TTFB и Speed Index отвечают на разные вопросы
Навигационный TTFB учитывает путь до первого байта ответа, включая соединение и переадресации. Большое значение требует разбирательства, но не доказывает недостаточность тарифа хостинга. Найдите, какой этап задерживает начало получения документа, и сопоставьте его с последующим появлением содержимого.
Speed Index оценивает визуальное заполнение по кадрам загрузки. Это не время завершения всех сетевых запросов и не характеристика работы формы после нажатия. Используйте его вместе с изображением страницы и другими метриками, чтобы понять, что именно было видно посетителю.
TBT не заменяет INP
Total Blocking Time полезен для поиска блокировок при лабораторной загрузке. Обычный запуск PSI не проходит весь путь пользователя, поэтому низкий TBT не доказывает отсутствие задержки при открытии фильтра или заполнении формы позднее.
INP оценивает задержку до следующего отображения после взаимодействия. Это не полное время серверной обработки заказа. Если кнопка быстро показала индикатор, но подтверждение приходит долго, нужно отдельно исследовать операцию. Определение раскрыто в документации INP. Устаревший FID не следует использовать вместо текущего INP при постановке задач по Core Web Vitals.
Как читать Insights и диагностические рекомендации
Открывайте замечания, связанные с проблемной метрикой. Изучайте конкретные ресурсы, элементы и время, а не только название пункта. Названия и группировка меняются между версиями инструмента. В Lighthouse 13 часть прежних диагностических аудитов производительности заменена новыми Insights; идентификаторы заменённых проверок удалены и из JSON. Поэтому инструкция по старому скриншоту может не совпадать с вашим отчётом.
LCP breakdown: на каком этапе потеряно время
В разбиении LCP смотрите первый ответ, задержку начала загрузки нужного ресурса, длительность скачивания и задержку отображения. Если файл уже получен, но элемент долго скрыт, одна дополнительная компрессия изображения может почти не помочь.
У текстового элемента без отдельного необходимого ресурса часть этапов может быть нулевой. Не ищите обязательную картинку в каждом отчёте. Зафиксируйте найденный элемент и его роль на странице: он может отличаться между телефоном и компьютером.
LCP request discovery: почему изображение обнаружено поздно
Этот пункт помогает проверить, доступен ли адрес LCP-картинки из исходного документа, не отложена ли она через lazy-loading и правильно ли задан приоритет. Условия описаны в LCP request discovery. Задача разработчику должна указывать конкретное изображение и задержанный этап.
Не переносите настройку высокого приоритета на всю галерею. Ресурсы конкурируют за загрузку, а мобильная версия может использовать другую картинку. После исправления проверьте, что действительно запрашивается нужный вариант и не появился лишний дублирующий запрос.
Render-blocking requests: какие зависимости задерживают показ
Разверните список и установите назначение каждого ресурса. Проверка блокирующих запросов помогает найти CSS и другие зависимости первого отображения. Наличие файла в списке не означает, что его можно удалить: он может обеспечивать меню или правильный вид первого экрана.
Попросите предложить способ сократить критический путь с сохранением оформления и функций. Вариант с критическими стилями требует аккуратной реализации; он не является обязательным условием хороших показателей для любого проекта. Приёмка должна охватывать разные экраны и состояния интерфейса.
Сдвиги, JavaScript и внешние подключения
При проблеме CLS сопоставьте указанные элементы с моментом изменения страницы. Сдвинувшийся блок может быть следствием появления другого блока выше. Это различие разобрано в руководстве по CLS. Удалять элемент, который лишь оказался сдвинутым, — плохая постановка задачи.
Замечания о длительной работе основного потока требуют изучения конкретного кода. А раздел Third parties помогает увидеть внешние подключения. Часть Insights носит информационный характер: присутствие пункта само по себе не означает провал проверки. Сначала выясните назначение аналитики, чата или платёжного компонента.
Кеш и расчётная экономия
Рекомендация по срокам кеширования касается повторного использования подходящих ресурсов. Не превращайте её в распоряжение публично кешировать личный кабинет или корзину. Уточните, кто управляет указанным файлом, можно ли изменить его заголовки и как будет обновляться новая версия.
Расчётная экономия времени — ориентир для выбранной модели, а не обещанный результат. Несколько рекомендаций могут затрагивать одну цепочку зависимостей. Складывать их оценки и обещать заказчику точное ускорение на полученную сумму некорректно. Реальный эффект подтверждается повторным измерением.
Как выбрать исправления и не превратить отчёт в бесконечный список
Начинайте с проблем, которые затрагивают важные страницы и заметны в значимых метриках или пользовательских действиях. Затем оцените подтверждённость причины, трудоёмкость и риск изменения. Маленькая правка общего шаблона иногда полезнее большого проекта ради одного замечания на редко посещаемом адресе.
| Наблюдение | Что проверить | Задача | Приёмка |
|---|---|---|---|
| Основной блок появляется поздно | LCP-элемент и его задержанный этап | Устранить подтверждённое ожидание нужного ресурса или показа | Сопоставимая серия LCP и правильный первый экран |
| Высокий TBT при загрузке | Какая работа занимает основной поток | Сократить или разделить ненужную раннюю обработку | Повторный тест и исправные важные действия |
| Заметные сдвиги | Момент и причина изменения размеров или положения | Стабилизировать конкретный блок и соседнее содержимое | Запись загрузки и взаимодействий без прежнего сдвига |
| Короткий кеш статических файлов | Владельца ресурса и схему обновления | Настроить подходящее хранение и смену версий | Повторный визит и получение обновлённых файлов |
Для каждой задачи запишите адрес, вкладку устройства, исходное наблюдение, предполагаемую причину и способ проверки. Разделяйте факт из отчёта и гипотезу специалиста. Фраза «плохой LCP» ещё не объясняет, требуется ли работа с сервером, изображением или отображением.
Сделайте отчёты PageSpeed частью контроля релизов: сохраните базовые показатели и список важных страниц. Для регулярного мониторинга доступности проекта познакомьтесь с SiteGuard и сопоставьте доступные проверки со своими задачами. Исправления по отчёту передавайте ответственному разработчику с понятными критериями приёмки.
Пример: как превратить замечание PageSpeed в рабочую задачу
Предположим, на мобильной карточке товара основное изображение определяется как LCP, а в разбиении заметна задержка до начала его загрузки. Это учебная ситуация, а не результат проверки конкретного сайта. Уменьшать все картинки подряд здесь рано: сначала нужно понять, почему нужный запрос начинается поздно.
Корректная задача может звучать так: «Проверить способ обнаружения основного изображения карточки на мобильном экране. Устранить подтверждённую задержку запуска запроса, сохранив подходящий размер картинки и работу галереи. После изменения повторить тот же тест и проверить выбор вариантов товара».
Разработчик выясняет причину, предлагает изменение и фиксирует результат. Если после раннего получения картинки основное время уходит на её отображение, расследование продолжается на новом этапе. Это нормальное уточнение, а не повод механически выполнять весь список рекомендаций.
Как проверить исправления после работы с отчётом
Повторите анализ тех же адресов и вкладок после публикации изменений. Сверьте версию страницы, окружение и содержимое скриншота. Сохраните несколько сопоставимых запусков, чтобы увидеть устойчивое изменение, а не выбрать единственный лучший результат.
В документации Lighthouse о вариативности объясняется необходимость учитывать разброс. Если значение колеблется, сначала установите причину различий. Изменение версии Lighthouse также фиксируйте: сравнение отчётов разных версий требует дополнительного внимания к составу проверок.
Проверяйте метрику и функцию вместе
После переноса скрипта убедитесь, что работают форма, фильтр и события аналитики. После изменения шрифтов проверьте читаемость и сдвиги. После настройки кеша — корректность цен, авторизации и обновления содержимого. Рост балла при сломанном оформлении заказа не является успешным результатом.
Для полевого эффекта наблюдайте за новыми посещениями с учётом периода агрегации. Не откладывайте исправление явного сбоя до обновления CrUX. Краткий итог работ должен показывать, что изменили, какая метрика улучшилась в сопоставимых условиях и какие функции проверены.
Сохраните результат так, чтобы к нему можно было вернуться
Ссылка на анализ удобна для обсуждения, но не является бессрочным архивом. В примечаниях к выпускам PSI для общедоступного снимка отчёта указан срок до 30 дней. Для длительной приёмки отдельно сохраните исходные значения, дату, адрес, настройки и снимки важных фрагментов. При автоматизации сохраняйте также исходный JSON.
Свяжите запись с конкретным выпуском сайта и задачей. Тогда через несколько месяцев можно будет понять, какое изменение обсуждалось, на какой странице оно проверялось и что считали успешным результатом. Одного изображения зелёного круга недостаточно: оно не объясняет условия и не позволяет восстановить ход проверки.
PageSpeed Insights API: для чего нужна автоматизация
API полезен, когда нужно регулярно получать лабораторные результаты для согласованного набора страниц и сохранять их в своей системе. Он возвращает структурированный ответ, который можно сравнивать между выпусками. Автоматизация должна учитывать ошибки запуска и изменения формата, а не записывать любую неполную выдачу как нулевой балл.
Какие параметры и поля сохранять
В справочнике runPagespeed указаны URL, strategy, category и locale. Явно выбирайте mobile или desktop: по умолчанию используется desktop. Без перечисления категорий выполняется Performance. Сохраняйте запрошенный и конечный адреса, fetchTime, lighthouseVersion, настройки, предупреждения и нужные метрики.
Версия API v5 не фиксирует версию Lighthouse. Обработчик не должен зависеть только от переводимых названий рекомендаций. Используйте актуальные идентификаторы, проверяйте наличие данных и учитывайте изменения схемы при обновлениях. Ключи и другие реквизиты не публикуйте в отчётах, открытом коде или общедоступных ссылках; условия запросов и квоты проверяйте в своём проекте.
Полевые данные лучше получать через отдельный интерфейс
В текущем руководстве PSI API Google предупреждает о планируемом прекращении включения CrUX и рекомендует отдельные интерфейсы. Само предупреждение не устанавливает, что изменение уже завершено. Новую интеграцию не следует строить на предположении о бессрочной доступности старых полевых полей.
Для актуального агрегата используйте CrUX API, для истории — CrUX History API. Сохраняйте период сбора отдельно от времени запроса. Отсутствующий показатель и ошибка обращения должны оставаться отдельными состояниями, а не превращаться в ложное улучшение графика.
Когда одного PageSpeed Insights недостаточно
Если задержка возникает после входа, при выборе сложного фильтра или только в конкретной сети, обычный публичный запуск может её не воспроизвести. Дополните отчёт записью соответствующего действия в браузере и наблюдением за нужным сегментом посетителей. PSI помогает определить направление, но не заменяет исследование всей работы приложения.
Когда ищут альтернативу PageSpeed Insights, полезно сначала назвать недостающую возможность: закрытый сценарий, управляемая локация, анализ запросов или история релизов. Для локальной записи взаимодействий подходит панель Performance Chrome DevTools. Выбор дополнительного инструмента определяется задачей, а не желанием получить более приятный балл.
Отчёт также не подтверждает успешную оплату, доставку письма или безопасность всей системы. В план приёмки включают отдельные проверки таких функций. Это позволяет использовать рекомендации PSI по назначению и не делать выводов за пределами измеренного сценария.
Если анализ не завершился
Сохраните точный текст ошибки и время запуска. Проверьте правильность URL и обычное открытие страницы, затем попросите ответственного сопоставить попытку с журналом сервера. Доступность из вашего браузера не доказывает, что внешний тест получает тот же ответ. Причину отказа нужно отличать от собственно медленной загрузки.
Не отключайте защиту всего сайта ради одного отчёта. Если запрос остановлен конкретным правилом, разберите его с администратором. Если проблема относится к самому запуску инструмента, используйте локальную диагностику и повторите проверку после устранения причины; не подменяйте отсутствие результата вымышленным баллом.
Частые вопросы о PageSpeed Insights
Можно ли пользоваться PageSpeed Insights бесплатно?
Веб-интерфейс доступен для проверки публичных страниц. Для автоматизированных обращений изучите действующие условия API и проекта. Не переносите правила ручной проверки на любое количество запросов из собственной системы.
Почему PageSpeed показывает разные баллы при повторном запуске?
Проверьте окружение, содержимое, внешние ресурсы и фактически открывшийся экран. Сохраняйте серию результатов и их разброс. Один необычный запуск сначала требует проверки условий, а устойчивое ухудшение — поиска причины.
Что важнее: полевые данные или лабораторная оценка?
Полевые данные показывают накопленный опыт наблюдаемой аудитории, лаборатория помогает исследовать конкретную загрузку. При постановке задачи нужны оба контекста. Свежую проблему нельзя игнорировать только потому, что история ещё выглядит хорошо.
Почему есть данные origin, но нет данных страницы?
Для отдельного URL может не хватать наблюдений, хотя для совокупности страниц их достаточно. Смотрите подпись области данных и не выдавайте общий агрегат за точную характеристику одного адреса.
Нужно ли исправлять все рекомендации ради 100 баллов?
Приоритет задают подтверждённые проблемы, охват страниц и влияние на важные сценарии. Информационный пункт не всегда требует изменения. Каждую правку оценивайте по метрикам и сохранности функций; погоня за числом сама по себе не является критерием готовности.
Почему в старой инструкции есть пункт, которого нет в отчёте?
Проверки переименовываются, объединяются и иногда удаляются. Сверьте версию Lighthouse и документацию текущего Insight. Не пытайтесь восстановить старый интерфейс и не связывайте автоматизацию с идентификатором, который уже исключён.
Сколько времени ждать изменения Core Web Vitals после выпуска?
Данные отражают скользящий период, поэтому новая версия постепенно влияет на агрегат. Проверяйте даты и достаточность наблюдений. Лабораторную приёмку и контроль рабочих функций проводите сразу после изменения, не ожидая обновления исторической оценки.