PageSpeed Insights: как читать отчёт о скорости сайта
Красный или жёлтый балл в PageSpeed Insights ещё не объясняет, что мешает посетителю пользоваться сайтом. Для рабочего вывода нужны адрес страницы, условия теста, конкретная метрика и границы данных. Разберём, как прочитать отчёт и превратить наблюдение в задачу с понятной проверкой результата.
Сначала сохраните адрес и условия проверки
Начните с точного URL. Главная, страница услуги и форма бронирования могут загружать разные изображения и сценарии. Проверка одного адреса не описывает автоматически весь сайт. Если после открытия произошёл переход на другой адрес, запишите и исходный, и конечный URL.
Для каждого отчёта сохраните дату, время с часовым поясом, выбранный режим для мобильного или настольного устройства и сведения о среде запуска, которые показывает инструмент. При повторной проверке понадобится именно эта запись, а не только снимок цветного круга. Условия и версия инструмента могут различаться.
Рядом укажите версию сайта или дату последнего изменения. Иначе команда может обсуждать два отчёта, снятых до и после публикации нового баннера, как результаты одной и той же страницы. Сохраните доступный отчёт или его содержательные снимки вместе с задачей.
Заранее определите пользовательский сценарий: прочитать условия, открыть меню, выбрать зал, отправить запрос. Эта запись поможет проверить полезность изменений. Ускорение загрузки первой части страницы и работоспособность последующей отправки формы требуют отдельных наблюдений.
Разделите данные посетителей и тестовый запуск
PageSpeed Insights объединяет два вида сведений. Полевые данные поступают из Chrome UX Report и описывают собранный опыт реальных пользователей за предыдущие 28 дней. Лабораторная часть использует Lighthouse для отдельного тестового запуска в заданных условиях.
Балл Performance от 0 до 100 относится к лабораторной оценке. Он не обозначает процент довольных посетителей, долю успешно открытых страниц или вероятность покупки. Lighthouse рассчитывает его по взвешенным метрикам; список рекомендаций сам по себе не является набором штрафных баллов.
В рабочем документе отведите этим сведениям разные строки. Например: «Полевые данные: мобильные устройства, конкретная страница, указанный период» и «Лабораторный запуск: мобильный режим, дата и условия». Даже если числа выглядят похожими, не объединяйте их в одну среднюю скорость сайта.
Мобильный и настольный режимы тоже читайте раздельно. Хороший результат настольного запуска не закрывает замечание по мобильному сценарию. Выбирайте приоритет по важности страницы для посетителей и воспроизводимой проблеме, а не по тому, где проще получить зелёный цвет.
Читайте LCP, INP и CLS как разные свойства страницы
Core Web Vitals охватывают загрузку основного видимого содержимого, отзывчивость и визуальную стабильность. Эти свойства не заменяют друг друга: быстро появившийся текст может сопровождаться медленно реагирующей кнопкой, а удобная кнопка — неожиданным сдвигом соседнего блока.
| Метрика | Что описывает | Хорошее значение |
|---|---|---|
| LCP — Largest Contentful Paint | Время появления крупнейшего содержательного элемента в видимой области при загрузке | Не более 2,5 секунды |
| INP — Interaction to Next Paint | Отзывчивость страницы на взаимодействия пользователя | Не более 200 миллисекунд |
| CLS — Cumulative Layout Shift | Неожиданные сдвиги расположения элементов | Не более 0,1; без единицы времени |
Для полевой оценки используют 75-й процентиль, обозначаемый p75. Если LCP на этом уровне равен 2,5 секунды, не менее 75% соответствующих наблюдений имеют значение не хуже этой границы. Это не среднее время и не оценка 75 баллов из 100.
Когда данных достаточно по всем трём метрикам, для прохождения оценки Core Web Vitals каждая должна быть в хорошем диапазоне. В PageSpeed Insights есть оговорка: если INP недоступен, оценка может опираться на LCP и CLS. При недостатке LCP или CLS оценка не формируется. Всегда сохраняйте фактически показанный статус и доступность метрик.
Не переводите CLS 0,1 в секунды и не сравнивайте его арифметически с LCP. Не называйте LCP временем полной загрузки всех ресурсов. В задаче специалисту оставляйте сокращение метрики, значение и единицу измерения: так замечание сохраняет исходный смысл.
Проверьте, относятся ли полевые данные к странице
Если данных для конкретного URL недостаточно, PageSpeed Insights может показать сведения для origin — сочетания протокола, домена и порта. В интерфейсе нужно различать данные страницы и такую более широкую группу. Сохраните выбранный уровень рядом с метриками.
Предположим, проверяется страница аренды небольшого зала, а отчёт показывает значения для origin. Это полезный общий сигнал, но он не доказывает, что именно эта страница имеет указанный LCP. Для замечания к конкретному адресу нужны относящиеся к нему наблюдения; лабораторный запуск можно использовать как отдельный вид диагностики.
Отсутствие полевых данных не означает успешное прохождение проверки или поломку сайта. Chrome UX Report применяет условия доступности и достаточности данных. Его выборка не равна автоматически всем посетителям из внутренней аналитики бизнеса; по отсутствующему отчёту нельзя восстановить число клиентов.
В такой ситуации запишите «полевые данные для страницы недоступны» и продолжайте доступную проверку. Не копируйте значения соседней страницы в пустую строку. Для нового или редко посещаемого адреса полезнее честно обозначить границу наблюдения, чем придумывать общий показатель.
Учебный пример: три запуска для страницы аренды зала
Представим вымышленный сайт аренды переговорных и страницу https://example.org/meeting-rooms/. Все числа, даты и результаты в этом примере придуманы для объяснения отчёта. Реальная проверка этого адреса, Salestudia или клиентского сайта здесь не проводилась.
| Запуск | Performance | LCP, секунды | TBT, миллисекунды | CLS |
|---|---|---|---|---|
| Первый | 58 | 4,1 | 420 | 0,01 |
| Второй | 71 | 3,4 | 260 | 0,01 |
| Третий | 65 | 3,8 | 330 | 0,01 |
| Медиана трёх значений | 65 | 3,8 | 330 | 0,01 |
В условном полевом отчёте за 29 сентября — 26 октября 2026 года выбраны мобильные устройства и данные именно страницы. Значения p75: LCP — 2,9 секунды, INP — 180 миллисекунд, CLS — 0,06. Данные по всем трём метрикам доступны. Хорошая граница LCP превышена, поэтому общая оценка Core Web Vitals не пройдена, хотя INP и CLS находятся в хорошем диапазоне.
В таблице приведены три лабораторных запуска одной версии этой страницы с одинаковыми заявленными условиями. Три запуска — удобный объём учебного упражнения, а не обязательное требование Google или достаточная выборка для любого исследования.
Сохраните разброс, а не только лучший балл
В учебной серии LCP меняется от 3,4 до 4,1 секунды. Если оставить только второй запуск с 71 баллом, часть наблюдения исчезнет. Сохраните все три отчёта, диапазон и выбранный способ сводки. Медиана здесь — среднее по положению значение после сортировки, а не среднее арифметическое.
Для LCP упорядоченный ряд выглядит как 3,4; 3,8; 4,1, поэтому медиана равна 3,8 секунды. Для баллов это 58; 65; 71, медиана — 65. Баллы в примере заданы как готовые значения условных отчётов: их нельзя восстановить только из трёх показанных метрик, поскольку таблица не содержит всех составляющих оценки Lighthouse.
Медиану трёх лабораторных запусков нельзя выдавать за полевой p75. В примере 3,8 и 2,9 секунды относятся к разным наборам наблюдений и условиям. Различие не доказывает ошибку отчёта. В реальной аудитории меняются устройства, соединения и обстоятельства посещения; лабораторный запуск описывает свою среду.
Для сравнения до и после исправления заранее выберите сопоставимый протокол и запишите изменения среды. Если одновременно сменились версия инструмента и содержимое страницы, отметьте оба обстоятельства. Одно случайно лучшее измерение не позволяет уверенно приписать весь выигрыш конкретной правке.
Не подменяйте INP лабораторным TBT
TBT, или Total Blocking Time, используется в лабораторной диагностике блокировок основного потока при загрузке. Он помогает искать возможные проблемы отзывчивости, но не заменяет полевой INP. Эти показатели нельзя сравнивать как два измерения одной величины.
В учебной таблице медиана TBT равна 330 миллисекундам. Полевой INP при этом равен 180 миллисекундам. Вычитать их и объявлять 150 миллисекунд задержкой формы нельзя: показатели получены разными способами и описывают разные наблюдения.
Отдельно пройдите важные действия: раскройте меню, смените вариант зала, выберите дату, исправьте ошибку ввода. Низкий TBT сам по себе не подтверждает, что каждое такое взаимодействие быстрое. Если задержка воспроизводится, передайте её шаги и условия специалисту для исследования.
Словесное замечание «кнопка зависает» тоже стоит уточнить. Укажите, на какой странице это происходит, после какого действия, как выглядит ожидание и воспроизводится ли оно повторно. Такой сценарий дополняет метрику и помогает искать конкретную причину.
Используйте рекомендации как начало диагностики
Предупреждение об изображениях ещё не доказывает, что именно главная фотография определяет медленный LCP. Сначала установите фактический LCP-элемент и этап, на котором возникает задержка. Он может не совпадать с тем объектом, который редактор считает самым заметным.
В задаче можно перечислить направления проверки: получение документа, обнаружение и загрузка нужного ресурса, готовность элемента к показу. Это вопросы к диагностике. Готовое предписание «сжать все фотографии вдвое» без проверки причины может ухудшить изображение и оставить исходную задержку.
Не складывайте предполагаемую экономию времени из разных рекомендаций в обещанный общий выигрыш. Изменения могут затрагивать одни и те же этапы. Для планирования укажите проблему, гипотезу и способ повторной проверки; ожидаемое улучшение подтвердите измерением после реализации.
Согласуйте ограничения заранее. Оптимизация не должна незаметно убирать важное содержимое, ломать форму, менять согласие на обработку данных или включать дополнительное отслеживание. Если для решения требуется изменение функции, его нужно описать и проверить как отдельную часть работы.
Передайте разработчику заполненную задачу
Продолжим учебный пример. Основание задачи — превышение хорошей границы полевого LCP и более медленный LCP в лабораторной серии. Конкретная техническая причина пока неизвестна. Сохранить это различие важнее, чем заранее назвать виноватый файл.
| Поле | Заполненный пример |
|---|---|
| Страница и сценарий | https://example.org/meeting-rooms/; прочитать условия и отправить запрос на зал |
| Наблюдение | Мобильные полевые данные страницы: LCP p75 — 2,9 с; лабораторная серия: LCP 3,4–4,1 с |
| Контекст | Учебное окно полевых данных 29 сентября — 26 октября; три условных запуска одной версии страницы |
| Гипотеза | Возможно, задерживается показ крупного элемента первого экрана; элемент и причина ещё не установлены |
| Первый шаг | Определить LCP-элемент, исследовать задержку и предложить подтверждённое исправление |
| Материалы | В реальной задаче приложить сохранённые отчёты, условия запуска и версию страницы |
| Ответственный и статус | Разработчик; ожидает диагностики, исправление не подтверждено |
| Проверка результата | Сопоставимая серия после изменения, проверка формы и дальнейшее наблюдение полевых данных |
После диагностики дополните карточку установленной причиной, согласованным изменением и датой публикации. Если гипотеза не подтвердилась, сохраните это в истории задачи. Не переписывайте исходное предположение как якобы известный заранее факт.
Приоритет определяйте вместе с владельцем сайта. Недоступная форма и умеренно медленное появление изображения требуют разных решений, даже если у второго замечания ярче цвет отчёта. Для принятия работы согласуйте критерии и ограничения до исправления.
Проверьте исправление в двух временных масштабах
После публикации сначала подтвердите, что открывается нужная версия страницы и сохранены её функции. Затем повторите лабораторные измерения по согласованному протоколу. Полевую историю рассматривайте отдельно: она охватывает период, внутри которого посетители могли видеть прежнюю версию.
| Проверка | Запись в результате | Когда выполнять |
|---|---|---|
| Версия страницы | URL, дата публикации, доступность исправления | После размещения изменения |
| Лабораторная серия | Все запуски, условия, диапазон и тот же способ сводки | После подтверждения версии |
| Пользовательские действия | Меню, выбор варианта, ошибки ввода и получение тестового запроса | При приёмке функций |
| Содержимое и внешний вид | Читаемость, изображения, отсутствие новых сдвигов в проверенных сценариях | На согласованных устройствах |
| Полевые показатели | Страница или origin, режим устройства, период и доступность метрик | При последующем наблюдении |
| Незакрытые замечания | Что осталось, кто отвечает и когда будет следующая проверка | В итоговой записи |
В условном отчёте с окном 29 сентября — 26 октября исправление, опубликованное 26 октября, не описывает опыт всех предыдущих дней. Поэтому требование немедленно получить новое значение за весь период некорректно. Запишите дату выпуска и смотрите, как меняется окно наблюдения.
Если результат серии улучшился, а форма перестала отправлять запрос, работу нельзя считать принятой по одному баллу. Для тестового обращения используйте согласованные данные и проверьте получение на стороне ответственного сотрудника. Отметка «кнопка нажимается» не подтверждает доставку обращения.
Завершите отчёт проверяемым выводом
Для упражнения вывод может звучать так: «В доступных мобильных полевых данных страницы LCP p75 составляет 2,9 секунды и превышает хорошую границу. INP и CLS находятся в хорошем диапазоне. Три условных лабораторных запуска дали LCP 3,4–4,1 секунды. Следующий шаг — установить LCP-элемент и причину задержки». Это запись наблюдений и задачи, без выдуманного результата исправления.
По такому отчёту нельзя рассчитать потерянную выручку или обещать определённую позицию в поиске. Google рекомендует хорошие Core Web Vitals, но прямо предупреждает: хорошие оценки не гарантируют верхние позиции. Для вывода о заявках нужны собственные бизнес-данные и отдельно продуманный способ сравнения.
Salestudia — агентство цифрового маркетинга из Idstein, Германия — проводит технический и поисковый SEO-аудит сайта. Его задача — установить проблемы в согласованном объёме и подготовить план исправлений с приоритетами. Реализацию всех изменений и дальнейшее сопровождение согласуют отдельно.
Для начала разбора подготовьте важные адреса, сохранённые отчёты, даты изменений и описание проблемного действия. Такой набор связывает технические измерения с конкретной страницей и помогает сформулировать работу, результат которой можно проверить.
Официальные и профильные ссылки
Эти материалы дают контекст для данных, правил и рекомендаций на странице.
- Google — PageSpeed Insights Источник проверен: 26.10.2026
- web.dev — пороги Core Web Vitals Источник проверен: 26.10.2026
- Chrome — оценка Lighthouse Источник проверен: 26.10.2026
- web.dev — различия лабораторных и полевых данных Источник проверен: 26.10.2026
- web.dev — Total Blocking Time Источник проверен: 26.10.2026
- Chrome — методология Chrome UX Report Источник проверен: 26.10.2026
- Google — Core Web Vitals и поиск Источник проверен: 26.10.2026
- Google — взаимодействие со страницей и ранжирование Источник проверен: 26.10.2026
Часто спрашивают
Ответы уточняют объём работ, роли, зависимости и способ оценки результата.
Балл Performance 60 означает, что сайт работает на 60%?
Нет. Это лабораторная оценка по метрикам Lighthouse. Она не показывает долю довольных посетителей, успешных обращений или выполненного объёма разработки.
Почему после обновления сайта полевые показатели сразу не изменились?
Они описывают предшествующее 28-дневное окно, которое может включать опыт работы со старой версией. Сохраните дату выпуска и проверяйте период следующего отчёта отдельно от нового лабораторного запуска.
Что делать, если данных реальных пользователей нет?
Зафиксируйте отсутствие данных и проверьте, не показан ли более широкий уровень origin. Продолжайте доступную диагностику, но не называйте отсутствие сведений успешным прохождением Core Web Vitals.
Достаточно ли низкого TBT, чтобы считать все кнопки быстрыми?
Нет. TBT помогает лабораторной диагностике, но не заменяет INP и проверку конкретных взаимодействий. Пройдите важные действия и сохраните условия воспроизводимой задержки.
Нужно ли ставить разработчику задачу получить 100 баллов?
Согласуйте конкретную проблему, метрики, условия повторной проверки и сохранность функций. Погоня за одним лучшим баллом не заменяет измерения и не гарантирует позиции в поиске или рост заявок.
Удобнее написать напрямую?
Коротко укажите компанию, рынок и задачу — так разговор будет предметнее.