Почему один прогон PageSpeed ничего не доказывает

Поправили шрифты, запустили PageSpeed — оценка упала на несколько баллов. Откатили правку, запустили снова — стала выше, чем была до всего. Знакомо? Это не правка сломала сайт и не откат его починил. Оценка плавает сама по себе, и выводы по одному прогону — это лотерея: можно выкинуть хорошую правку или оставить вредную.

Это четвёртая часть цикла «PageSpeed без мифов». Разбираем, откуда берётся разброс и как мерить так, чтобы цифрам можно было верить.

Насколько плавает оценка

• Обычный разброс — до ±10 баллов между прогонами одной и той же страницы без единой правки. Для страниц «на грани» (85–95) этого хватает, чтобы цвет оценки прыгал между оранжевым и зелёным.
• Изредка — выброс в разы. На одном сайте тот же самый билд давал Speed Index 9–16 секунд при обычных 1,3. За один рабочий день так случилось пять раз; повторный прогон каждый раз возвращал норму.

Правило: серия, а не прогон

1. Минимум три прогона до правки и три после. Сравнивайте серии, а не лучший прогон с худшим.
2. Выбросы — выкидывать, но по признаку, а не по желанию. Надёжный признак сбоя: время ответа документа в прогоне аномальное (например, 2,4 с вместо обычных 0,3 с). Такой прогон измерил сеть проверки, а не вашу страницу.
3. Смотрите не только на оценку. Модельный и наблюдаемый LCP, вес окна первой отрисовки — они плавают гораздо меньше оценки и честнее показывают, подействовала ли правка.

С локальным Lighthouse из третьей части серия запускается одной строкой, а скрипт разбора печатает по каждому прогону главные цифры:

for i in 1 2 3; do
  npx lighthouse@12 https://example.ru/ --only-categories=performance \
    --chrome-flags="--headless=new" --output=json --output-path=lh-$i.json --quiet
done
for f in lh-*.json; do echo "== $f"; node lh-window.js $f | head -4; done

Три способа обмануть себя ещё до прогона

1. Холодный кэш

Если у сайта есть кэш страниц, первый заход после его сброса (например, сразу после выката) собирает страницу заново — это медленно. Lighthouse честно зафиксирует «регрессию», которой нет у живых посетителей: они получают страницу из кэша. Перед серией откройте страницу один раз и только потом мерьте.

2. Сборка для разработки

В режиме разработки скрипты не сжаты и не минифицированы. На одном из наших сайтов аудит насчитал так 42 КБ «лишнего» JavaScript, которого в боевой сборке нет, а окно первой отрисовки выглядело тяжелее, чем на самом деле. Мерить нужно ту сборку, которая уйдёт на сайт.

3. Тестовый сервер вместо боевого

Тестовая копия обычно пустая: нет трафика, другой кэш, другая база, иногда другой сервер. Мы ловили ситуацию, когда правка на тесте не давала ничего — там и так было 96–100 при отрисовке за 300 мс, — а на боевом сайте та же правка подняла товарную страницу с 92 до 95–98. Тест годится, чтобы убедиться, что ничего не сломалось; цифры для выводов — с боевого сайта или с его точной копии.

Что записывать после каждой серии

Что	Зачем
оценка (все прогоны серии)	видно разброс, а не только «лучший»
LCP в отчёте и наблюдаемый LCP	разрыв между ними — подпись модели, и он меняется после правки раньше оценки
наблюдаемая первая отрисовка	стала ли страница рисоваться раньше
вес и число запросов в окне первой отрисовки	прямой результат правки: ушли ли из окна шрифты, видео, картинки

Почему бы не взять лучший прогон и не успокоиться?

Потому что лучший прогон есть и у сломанной страницы. Сравнивая лучший «после» с обычным «до», легко поверить в правку, которая ничего не дала, — и потом искать, почему у посетителей ничего не изменилось.

Сколько прогонов достаточно?

Три — минимум, чтобы заметить выброс. Если результаты серии сильно расходятся между собой, сделайте пять. Если разница между «до» и «после» меньше разброса внутри серии — правка, скорее всего, ни на что не повлияла.

В следующих частях — ещё две ловушки замеров: эксперимент «заблокирую файл и посмотрю», который врёт, и зонды, которые меряют сами себя.