Два прогона PageSpeed дают разные оценки, и команда принимает один удачный результат за исправление. Для диагностики нужны одинаковые условия, несколько измерений и понимание различия лабораторного опыта и данных реальных посетителей.
Зафиксируйте параметры лабораторного опыта
Запишите страницу, версию, устройство или эмуляцию, параметры сети и CPU, состояние кеша и сценарий. Сравнивайте соответствующие условия до и после. Лабораторная мобильная проверка не представляет автоматически весь набор реальных телефонов.
Лабораторные и полевые данные отражают разные условия и могут показывать различающиеся результаты. Официальная документация.
В протоколе укажите URL, версию страницы, viewport, режим устройства, ограничение сети и CPU. Добавьте местоположение измерения, браузер и его версию, если они доступны. Не считайте стандартный пресет mobile полноценной моделью всех телефонов. Он создаёт определённые лабораторные условия. Если тест выполняется через сервис, сохраните ссылку на конкретный результат и его настройки. Для ручного браузерного опыта отметьте открытые расширения и фоновые нагрузки, которые могут влиять на процесс. Цель — сделать сравнение повторяемым, а не приблизительно похожим.
Холодный и тёплый кеш проверяются раздельно
Учебные сценарии в таблице задают ожидаемое поведение; фактические ответы своего сайта заносите отдельно.
| Сценарий | Отличие | Решение | Проверка |
|---|---|---|---|
| Холодный кеш | Первая загрузка | Отдельная серия | Сохранить условия |
| Тёплый кеш | Повторный вход | Отдельная серия | Не смешивать с первым |
| Эмуляция mobile | Лабораторный режим | Записать CPU и сеть | Не все телефоны |
| Полевые данные | Реальные посещения | Указать период | Отдельное сравнение |
Первая загрузка без кеша и повторный вход с сохранёнными ресурсами решают разные вопросы. Проводите их отдельными сериями. Укажите, очищены ли HTTP-кеш, service worker и предусмотренное состояние приложения. Не удаляйте пользовательские данные на production ради лабораторного теста; используйте собственный тестовый профиль. Сторонние сервисы могут сохранять состояние независимо, поэтому отмечайте их фактические запросы. Если до правки проверяли cold, а после warm, большая разница ещё не говорит об оптимизации. Сравните соответствующие режимы, сохранив исходные условия и реальные загруженные ресурсы.
Сохраните серию, а не лучший запуск
Сохраните настройки теста и результаты нескольких прогонов: отдельные метрики, waterfall и ошибки. Отметьте холодный и тёплый кеш, время запуска и возможное изменение сторонних ресурсов. Выброс не удаляйте без объяснения.
Выполните несколько прогонов одного неизменного релиза и сохраните все результаты. Для сводки можно выбрать медиану и показать диапазон; это предложенная методика, а не универсальная гарантия точности. Не выбрасывайте медленный запуск только потому, что он портит вывод. Посмотрите waterfall, ошибки и изменение сторонних ответов. Если причина выброса известна, опишите её отдельно. Для каждого результата храните время, метрики и существенные условия. Такая серия показывает разброс лаборатории и позволяет оценить, превышает ли ожидаемое изменение обычные колебания теста.
Учебный протокол до и после одной правки
Учебный протокол выполняет несколько холодных прогонов одного URL при фиксированной сети. Затем проверяется одна правка изображения. Нельзя сравнивать первый холодный результат со вторым тёплым и приписывать всю разницу оптимизации.
Учебный опыт проверяет одну карточку товара с тяжёлым главным изображением. Сначала выполняется серия cold с фиксированной сетью, затем меняется только вариант изображения и повторяется серия. Bundle, контент и сторонние подключения остаются теми же в тестовой модели. Сравните начало запроса картинки, её получение и момент отображения. Если одновременно включён новый кеш, это уже другая комбинация причин. Распишите изменения и при необходимости разделите опыт. Не публикуйте выдуманные цифры: учебный протокол задаёт, что измерять, а таблица фактов заполняется реальными результатами вашего теста.
Сравните метрики и механизм, а не общий балл
Проводите серию на неизменной версии, затем серию после одной подтверждённой правки. Вывод делайте по конкретной метрике и наблюдаемому механизму. Полевые сведения используйте как отдельный источник с собственным периодом.
Общий балл способен меняться из-за разных компонентов и скрывать конкретное ухудшение. Сравните отдельные метрики и их причины. Для LCP проверьте кандидат и этап загрузки, для взаимодействий — реальный сценарий, для сдвигов — соответствующее отображение. Нельзя объявлять улучшение INP на основании одной быстрой загрузки страницы без взаимодействия. Если изменился LCP-элемент между прогонами, выясните почему: viewport, контент или шрифт могли повлиять. В выводе называйте улучшенный механизм и охват, а не превращайте один удачный запуск в характеристику всего сайта.
Чем отличаются сведения реальных пользователей
Общая оценка скрывает разные причины. Улучшение одного лабораторного LCP не доказывает улучшение INP у всех пользователей, а сетевое ограничение не воспроизводит полностью производительность реального устройства.
Полевые данные отражают реальные устройства, сети и поведение в своём периоде. Они не обязаны совпадать с вашим лабораторным пресетом. Сохраняйте источник, период и уровень агрегации: конкретный URL или группа страниц. Если данных недостаточно, это не равно нулевой задержке. После релиза исторический период может включать старую и новую версию, поэтому не ожидайте мгновенного совпадения. Лаборатория полезна для диагностики и проверки правки в контролируемых условиях; полевые наблюдения помогают понять распространённость у реальных посетителей. Эти результаты объясняют друг друга, но не заменяют.
Приёмка воспроизводимости и границ вывода
Приёмка содержит две сопоставимые серии, сохранённые параметры и проверку пользовательской функции после оптимизации. Если речь об изображении, проверьте качество и соответствие товара; если о скрипте — корректность действия. Отметьте обычный разброс и изменение критического этапа. Сохраняйте ограничение вывода: конкретный URL, пресет, релиз и сценарий. Дополнительно назначьте наблюдение доступных полевых данных, не обещая общий процент роста конверсии. Повторный тест требуется после существенного изменения ресурсов или методики, а многократный поиск максимально высокого балла без новой причины не добавляет доказательств.
Критерии завершения проверки
Серии сопоставимы по условиям, исходные результаты сохранены, изменение связано с проверяемой причиной. Отдельно указаны лабораторные и полевые данные и охват устройств.
- Холодный кеш: Сохранить условия. Зафиксируйте фактический результат и адрес проверенного сценария.
- Тёплый кеш: Не смешивать с первым. Зафиксируйте фактический результат и адрес проверенного сценария.
- Эмуляция mobile: Не все телефоны. Зафиксируйте фактический результат и адрес проверенного сценария.
- Полевые данные: Отдельное сравнение. Зафиксируйте фактический результат и адрес проверенного сценария.
Для смежных вопросов: Скорость сайта и конверсия: сколько стоит каждая лишняя секунда загрузки и Что проверить на сайте сразу после публикации изменений. Отдельные проверки сайта собраны на странице технического аудита reChecker.