Измерение производительности браузера с User Timing API

User Timing API позволяет приложению назвать точки собственной работы и измерить интервал между ними. Она отвечает на ограниченный вопрос вроде «сколько заняла проверка оплаты в этом выпуске?». Это не тест устройства и не сигнал личности. Полезное измерение начинается с видимого результата, задает объяснимые границы и записывает только поля, необходимые для решения.

Метки и измерения производительности

performance.mark(name) записывает именованную точку на временной шкале документа. performance.measure(name, startMark, endMark) создает интервал между двумя метками. Выбирайте стабильные имена видимых шагов: search-submit-start, results-visible, payment-validation-complete.

performance.mark('cart-submit-start');
try {
  await validateCart();
  performance.mark('cart-submit-end');
  performance.measure('cart-submit', 'cart-submit-start', 'cart-submit-end');
} finally {
  performance.clearMarks('cart-submit-start');
  performance.clearMarks('cart-submit-end');
}

Спецификация W3C User Timing Level 3 определяет записи, а справочник MDN описывает методы. Проверяйте наличие API, обрабатывайте отсутствующую метку или отклоненную операцию и сохраняйте основную задачу работоспособной. try/finally очищает успешный, ошибочный и отмененный путь; параллельным запускам нужны собственные имена, чтобы один компонент не удалял метки другого.

Измеряйте принадлежащие приложению сценарии

Начните со сценария и критерия приемки. Для поиска измерьте путь от отправки до видимых результатов, а запрос, разбор и отрисовку разделяйте только ради конкретного решения. Navigation Timing, Resource Timing и User Timing различны: метка приложения не доказывает длительность сети или сервера.

Отмечайте границы под контролем команды. Если конец задает сторонний виджет, называйте его наблюдением. Сохраняйте отмену и повтор, используйте короткий fixture id, не содержимое страницы и не идентификатор аккаунта.

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

Итог	Данные	Действие
Обе	время + id	дальше
Нет API	нет	пропуск
Ошибка	статус + время	ошибка
Отмена	статус	сохранить
Поздно	устарело	не менять

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

Минимизируйте данные

Собирайте только имя измерения, агрегат или корзину длительности, метку выпуска, fixture id и результат. Не собирайте URL, строки запросов, текст, аккаунты и долгую историю. До экспорта определите принимающую систему, группу доступа, срок хранения и путь удаления. Даже без текста повторяющиеся события, связанные временными метками или другими записями, могут описывать сеанс. Если решению не нужна диагностика каждого запуска, агрегируйте данные до передачи. Ограничьте диагностику окном инцидента или теста, задайте срок действия, затем удалите ключ связи и подробную трассировку. Короткий id допустим на это окно, затем он должен истечь. Экспортируйте белый список и очищайте записи; не соединяйте метки с другими свойствами браузера для профилирования.

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

Интерпретируйте шумные результаты

Кэш, сеть, нагрузка сервера, планирование CPU, состояние страницы, версия и параллельная работа меняют распределение. Сравнивайте одинаковые fixture, маршрут, выпуск и окно; используйте процентили и размер выборки, а не одно среднее. Рост p95 при прежней медиане указывает на хвост; сдвиг всех процентилей может указывать на изменение среды.

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

Параллельным запускам нужны собственные имена; общее имя может связать неверные начало и конец.

Отклоненная Promise может пропустить конечную метку, поэтому сохраняйте ошибку и очищайте начальную метку.

При отмене сначала аннулируйте запуск, чтобы поздний ответ не изменил текущий экран.

При отсутствии API not-measured не означает нулевую длительность, а сценарий должен продолжиться.

Fixture должен задавать синтетический ввод, ограниченные ожидания и сброс без записей для следующей проверки.

Перед каждым запуском удаляйте только метки с префиксом fixture; не очищайте временную шкалу других компонентов.

Повторяемое измерение не требует одинакового времени: важны одинаковый переход состояния и правила очистки.

Укажите, входят ли в интервал повторы, очередь, анимация или ожидание отрисовки, и сохраняйте определение между выпусками.

Метка не должна блокировать отправку или заменять исходную ошибку, если очистка завершилась сбоем.

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

Записывайте ревизию fixture, класс маршрута, выпуск браузера, окно и размер выборки.

Отделяйте итог от подробной диагностики и удаляйте временные идентификаторы после разрешенного окна.

Если смысл метки изменился, начинайте новую серию и не смешивайте разные интервалы.

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

Статус superseded объясняет отсутствие измерения без выдуманной длительности.

Отсутствующая запись может быть полезным свидетельством отмены, ошибки или смены страницы.

Чек-лист выпуска

Зафиксируйте имена, владельцев границ, входы fixture, конфигурацию браузера, окно, агрегацию и срок хранения. Проверьте поддерживаемый и неподдерживаемый API, ошибки, отмену, повторы, повторные запуски, локализацию и восстановленную страницу. Убедитесь, что очистка не удаляет записи другого компонента, и проверьте desktop и mobile.

Безопасная последовательность: определить один собственный вопрос; отметить границы; измерять только при наличии обеих точек; очистить; агрегировать сопоставимые запуски; оставить минимум доказательств. Так производительность остается объяснимой без скрытого измерения приложения.

Публичные источники

• W3C User Timing Level 3
• MDN: User Timing API
• BotBrowser: Advanced features

Материалы по теме

• Временные сигналы и отпечаток браузера
• Оптимизация производительности