Как проверить скорость сайта: от симптома к причине и повторному замеру

Выберите сценарий, который действительно мешает пользователю

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

Сформулируйте наблюдение через действие. Например: «после открытия страницы услуги нажимаю меню; панель появляется с задержкой». Укажите точный адрес, состояние страницы и момент действия. Если симптом зависит от авторизации, устройства или длинного списка, запишите это сразу.

Не начинайте с одновременной замены хостинга, картинок и всех скриптов. После такого набора трудно установить, что помогло, что не изменилось и что сломалось. Сначала нужен наблюдаемый участок и гипотеза, которую можно проверить отдельно.

Для одного отчёта выберите один главный вопрос: задержка загрузки, реакция после действия или стабильность расположения. Остальные проверки сохраняйте как регрессию. Так исправление меню не будет принято ценой пропавшей клавиатурной навигации.

Если задача пока сформулирована только как отсутствие обращений, сначала разделите трафик, предложение и технические препятствия. Это шире скорости; для такой развилки есть диагностика отсутствия заявок.

Используйте полевые данные как контекст, а не готовый диагноз

Полевые данные показывают опыт реальных пользователей за период. PageSpeed Insights использует данные CrUX за предыдущие 28 дней. При недостатке выборки для страницы отчёт может перейти к уровню origin, то есть сайта в целом; иногда полевые данные недоступны и на этом уровне.

Поэтому рядом с результатом записывайте уровень агрегации, устройство и период. Данные всего сайта нельзя молча подписывать именем одной страницы. Отсутствие выборки не означает нулевую задержку или установленный провал.

Это рекомендации Google, ориентированные на 75-й процентиль с разделением mobile и desktop, а не наши измерения. Общая оценка Lighthouse — составной лабораторный балл. TBT в таком отчёте не нужно переименовывать в измеренный INP пользователей.

Используйте контекст для выбора приоритета. Если проблема касается одного действия в меню, хороший результат загрузочного теста не опровергает наблюдение. Нужна запись именно этого действия.

Зафиксируйте условия до первого замера

Сравнение имеет смысл, если понятно, что осталось одинаковым. Запишите версию страницы и инструмента, устройство, браузер, размеры окна, сеть, состояние кеша, авторизацию и данные. Для взаимодействия добавьте точную последовательность действий.

Тест холодного открытия и повторное открытие уже посещённой страницы могут отвечать на разные вопросы. Выберите режим под задачу и назовите его. Если используете искусственное замедление CPU или сети, сохраните настройку; это модель, а не измерение конкретного телефона.

Количество прогонов выбирают так, чтобы увидеть вариативность и проверить вывод. Не называйте произвольное число обязательным правилом Google. Если результаты сильно различаются, это повод изучить условия, а не выбрать самый красивый скриншот.

Свяжите запись браузера с конкретной причиной

Trace — запись событий работы браузера во времени. Она помогает понять, что происходило в момент задержки: загрузка ресурса, выполнение JavaScript, расчёт расположения или отрисовка. Запись нужна вместе с выбранным сценарием, иначе объём данных не превращается в ответ.

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

Например, длинная работа JavaScript рядом с нажатием — кандидат для изучения, но ещё не основание удалить весь скрипт. Нужно определить выполнявшуюся функцию и её роль. Аналогично позднее главное изображение требует разбора его загрузочной цепочки, а не автоматической смены формата всех изображений.

Разделяйте факт и гипотезу. «На выбранном участке есть расчёт layout» — наблюдение записи. «Эту работу вызывает конкретная последовательность чтений и изменений» — вывод, которому нужна связь с кодом. «Перестановка операций уменьшит работу» — гипотеза изменения до контрольного повторения.

Если данных недостаточно, оставьте причину неподтверждённой и определите следующий нужный след. Это полезнее уверенного диагноза по одному общему баллу.

Заполненный учебный отчёт: лишний layout в официальном примере Chrome

В официальном tutorial Chrome рассматривается demo с движущимися квадратами. Документ показывает связь событий Layout с функцией app.update: она меняет стиль и затем читает положение элементов. Для вычисления положения браузеру приходится пересчитывать layout. В примере есть переключение Optimize для сравнения вариантов.

Это опубликованный учебный пример, а не наш собственный trace и не работа для клиента. Численные результаты здесь не приводятся. Интерфейс tutorial основан на Chrome 129; в другой версии расположение инструментов может отличаться.

В своём отчёте замените предмет, условия и доказательство собственными данными. Не копируйте готовую причину только потому, что тоже видите задержку. Пример показывает устройство аргумента: изменение должно следовать из записи, а вывод — из контрольного сравнения.

Выберите одно изменение и подготовьте сравнение

Когда причина подтверждена, сформулируйте небольшое изменение с ожидаемым техническим эффектом. Например: убрать повторную обработку одного события или изменить порядок операций в установленном участке. Не объединяйте это с редизайном, заменой сервера и новым набором данных.

До правки сохраните исходную версию и запись. После правки повторите сценарий с теми же условиями. Если изменились версия браузера, окно или состав страницы, отметьте это как ограничение сравнения.

Проверьте не только след, но и задачу пользователя. Открывается ли меню? Не исчезли ли нужные пункты? Сохранились ли фокус, управление клавиатурой и режим уменьшенного движения, если они относятся к изменённому интерфейсу? Уменьшение работы ценой сломанного действия не считается успешным исправлением.

В выводе пишите, что подтверждено: изменился конкретный участок работы при данном сценарии и данных. Если численные результаты ещё не получены, не подставляйте ориентиры или обещанный процент ускорения. Не превращайте лабораторное сравнение в утверждение о продажах.

Контроль после существенных изменений можно включить в протокол приёмки сайта, сохранив этот отчёт как отдельное доказательство причины и результата.

Соберите пакет доказательств, который можно перепроверить

Передайте не только итоговую картинку, но и исходную запись. Для учебной организации файлов можно назвать их trace-before.json и trace-after.json; это пример имён, а не созданные здесь артефакты. Рядом храните текст условий и описание одного изменения.

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

Если одна из связей отсутствует, сузьте вывод. Можно подтвердить наличие задержки, но не её причину; можно объяснить причину, но ещё не принять исправление. Такое разделение делает отчёт полезным для следующего решения.

Уберите из передаваемых материалов чужие персональные сведения и секреты. Если запись связана с закрытым разделом, заранее согласуйте тестовый набор и круг получателей. Доказательство должно быть воспроизводимым в разрешённом контуре, а не требовать просмотра чужого аккаунта.

Завершите отчёт решением, а не новой оценкой

В отчёте должны оставаться ссылка на версию, условия, исходное наблюдение, доказанная причина, изменение, повторная запись и ограничение вывода. Отдельно укажите нерешённые вопросы. Это позволяет другому специалисту проверить логику без пересказа созвона.

Решение может быть разным: принять точечную правку, продолжить поиск причины, повторить неполный замер или вернуть изменение из-за регрессии. Запишите основание. Если лабораторный результат стал лучше, а симптом сохранился, задача ещё не закрыта.

Полевые данные исторические: после исправления они не превращаются мгновенно в результат новой версии. Следующий контроль планируют с учётом доступности данных и периода. При отсутствии выборки продолжайте воспроизводимый лабораторный контроль, честно сохраняя его границы.

Скорость стоит проверять на конкретной сборке, а не объявлять свойством одной CMS. Если выбираете платформу, используйте сравнение WordPress и Битрикс для вопросов архитектуры; этот материал оставьте инструкцией по измерению работающего интерфейса.

Для передачи задачи специалисту приложите адрес, описание действия, условия и сохранённые отчёты. Просьба «сделать сто баллов» не заменяет цель. Понятный вопрос «почему задерживается это действие и как проверить исправление» задаёт проверяемую работу.