Когда стандартных отчётов мало, пишут свои зонды: скрипт в браузере, который следит за вёрсткой, или серию запросов curl по сайту. Это сильный инструмент — пока зонд не начинает мерить сам себя. За время работы мы попались на это несколько раз. Каждый раз вывод выглядел убедительно и был неверным.
Это шестая часть цикла «PageSpeed без мифов» — пять ловушек, которые стоит знать, прежде чем доверять своему замеру.
1. Зонд сам тормозит страницу
Мы искали, почему блок появляется поздно, и повесили наблюдение: на каждом кадре (requestAnimationFrame) спрашивать у блока его положение (getBoundingClientRect). Зонд показал задержку 7448 мс. Настоящая задержка была 1499 мс: DOMContentLoaded на 1327 мс, load на 1485 мс.
Причина: запрос геометрии на каждом кадре заставляет браузер пересчитывать вёрстку — постоянно, пока страница ещё строится. Зонд замедлил страницу в пять раз и честно это замерил.
Как надо: опрашивать редко — setInterval раз в 50 мс вполне достаточно для таймлайна загрузки. А лучше брать готовые события: PerformanceObserver для отрисовок и сдвигов вёрстки ничего не замедляет.
2. HEAD и GET — разные страницы для кэша
Проверка «отдаётся ли страница из кэша» через curl -I выглядит естественно: нужны только заголовки. Но -I отправляет запрос HEAD, а метод запроса входит в ключ кэша nginx. HEAD и GET попадают в разные ячейки: можно часами «прогревать» кэш, который посетители никогда не увидят.
# не так: curl -I https://example.ru/
curl -s -o /dev/null -D - https://example.ru/ # GET, печатаем только заголовки3. Кэш-бастер, который ломает страницу
Чтобы обойти кэш, к адресу добавляют случайный параметр. В WordPress с этим надо осторожно: часть коротких имён параметров — служебные. Например, ?m=… — это архив записей за месяц: вместо нужной страницы вы получите совсем другую и будете мерить её. Берите имя, которого точно нет у движка, — ?probe=….
4. Массовый обход меряет свою нагрузку
Хотите проверить скорость всех страниц — запускаете обход: 295 страниц подряд, без пауз. Получаете «каждая отвечает около 2 секунд, всё плохо». Те же страницы по одной, с паузой, отвечали за 0,19–0,26 с из кэша.
Обход сам создал нагрузку: сервер обрабатывал десятки запросов одновременно, а на части страниц ещё и запускал фоновое обновление кэша. Медленные ответы массового обхода всегда перепроверяйте поштучно.
5. Замер, который всё починил
Самая коварная ловушка — когда первый запрос зонда сам меняет то, что он меряет. Проверяем, какие страницы «холодные» (не в кэше): первый же запрос такую страницу прогревает. Повторная проверка через минуту показывает «всё в кэше», и кажется, что проблема решилась сама.
Как надо: оставлять контрольную группу — часть страниц, которых зонд не касается, — и сравнивать с ней. И записывать результат первого касания, а не последнего.
Вопросы, которые стоит задать себе до вывода
- Мог ли зонд повлиять на результат? Нагрузка, пересчёт вёрстки, прогрев кэша, дополнительные запросы.
- Тот ли запрос я делаю, что и посетитель? Метод, параметры, заголовки, куки — всё, что входит в ключ кэша и влияет на ответ.
- Совпадает ли результат с другим способом замера? Если зонд говорит 7 секунд, а события браузера — полторы, прав, скорее всего, не зонд.
- Повторяется ли он? Один замер — не результат (четвёртая часть).
Замеры расходятся с тем, что видят пользователи?
Пришлите адрес и опишите, что меряете, — помогу разобраться, где правда.
// загружаю комментарии…