Почему один прогон PageSpeed врёт — и как мерить стабильно

Запустите PageSpeed Insights для одной и той же страницы дважды. С большой вероятностью вы получите два разных числа — иногда с разницей в 15–20 баллов. Это не ошибка инструмента. Это физика: сеть, кеш, нагрузка на сервер и узел CDN, до которого дотянулся тестовый агент.

Проблема в том, что решения принимаются по одному прогону. «Было 62, стало 78 — релиз удался». Или наоборот: команда неделю чинит регрессию, которой не было.

Откуда берётся шум

Холодный кеш. Первый запрос после деплоя идёт мимо CDN и серверного кеша. Он честно медленный — но так сайт видит один пользователь из тысячи.
Узел CDN. Тестовый агент может попасть на узел, где вашей страницы ещё нет. Это отдельный сценарий, а не «реальная скорость».
Сторонние скрипты. Чат, аналитика и рекламные теги отвечают с разной задержкой в каждом прогоне.
Нагрузка. В час пик тот же сервер отвечает иначе, чем ночью.

Протокол, которому можно верить

В лаборатории каждый замер — это серия, а не выстрел:

Прогрев кеша ×2. Два холостых прохода, чтобы CDN и серверный кеш отдавали страницу так же, как живым пользователям.
N тёплых проходов с паузой. Серия замеров, разнесённых во времени, — чтобы не мерить один и тот же момент.
Медиана, а не рекорд. Лучший результат приятно показать начальству, но он описывает не сайт, а удачу.
Сверка с CrUX. Лабораторные цифры сравниваются с данными реальных пользователей Chrome — там, где их достаточно.
Три сценария. Реальный, худший и «холодный» узел CDN: видно не только как есть, но и где край.

Один замер — фотография. Серия — кино. Решения принимаются по кино.

Что это меняет на практике

Когда шум убран, регрессия перестаёт быть мнением. Если медиана серии выросла на 300 мс после релиза — это релиз, а не погода. Такой цифре можно доверить гейт в CI: релиз не уйдёт, если бюджет нарушен, и никто не будет спорить, «показалось» или нет.

Именно поэтому каждый отчёт лаборатории воспроизводим: протокол записан вместе с результатом, и его можно повторить.