Что измеряет время загрузки ресурса

Основная идея

PerformanceResourceTiming хранит отметки DNS, connect, secureConnection, request, responseStart и responseEnd. Нулевые значения могут означать повторно использованное соединение или ограничение доступа к данным стороннего origin.

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

Что подтверждает первичный источник

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

Первичный источник «MDN PerformanceResourceTiming» задаёт техническую основу, но не описывает конфигурацию каждого клиента и поставщика. Читайте нормативную формулировку рядом с датой и версией документа, затем подтверждайте поведение в своей программе. Если интерфейс обещает больше, чем источник, помечайте это как свойство продукта, которое нужно проверить отдельно.

Практический стенд

На своём origin загрузите один ресурс с Timing-Allow-Origin и второй без него. Через performance.getEntriesByType('resource') сравните DNS, connect, secureConnection, requestStart, responseStart и responseEnd напрямую и через прокси. Для повторного запроса проверьте transferSize и кэш. Сторонний ресурс без разрешающего заголовка должен скрыть часть фаз.

Проверка шаг за шагом

Для своего ресурса добавьте Timing-Allow-Origin, затем вычислите TTFB и время передачи из соответствующих пар отметок. Сопоставьте метрики с размером ответа и протоколом, а не складывайте все интервалы без разбора.

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

Записывайте DNS, connect, TLS, time to first byte, total и число переданных байтов. Используйте медиану, а не лучший результат. Если медленным оказался только первый запрос, причиной может быть DNS, TLS или холодный кэш. Если растёт время передачи большого файла, проверяйте канал, потери и ограничения сервера; смена IP без этих данных ничего не доказывает.

• Добавить Timing-Allow-Origin
• Сравнить ресурс без заголовка
• Проверить transferSize
• Сопоставить прямой и прокси-маршрут

Какие данные сохранить

Храните URL в обезличенном виде, initiatorType, protocol, transferSize и доступные timestamp. Нулевое значение не всегда означает мгновенную фазу: оно может быть скрыто политикой timing information.

В отчёт включают размер файла, расположение контрольного сервера, тип подключения, пять исходных значений и медиану. Для 10 МБ указывайте, что это скорость между клиентом и проверочным endpoint WorldProxy через выбранную прокси, а не универсальная скорость всего интернета. Отдельно отмечайте HTTP-ошибки: быстрая страница 403 не является успешным замером.

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

Как читать результат

Resource Timing не показывает внутреннюю очередь прокси и не измеряет скорость всего канала. Кросс-доменные подробности скрываются без разрешающего заголовка.

Resource Timing отражает взгляд браузера, использует connection reuse и ограничивается политикой origin. Он не заменяет серверные метрики и сетевой packet trace.

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

Разбор рабочего решения

Для темы «Что измеряет время загрузки ресурса» заранее задайте бюджет измерения. Один цикл может включать прогрев, пять маленьких запросов, пять передач файла и такой же прямой контроль. Между тяжёлыми циклами нужна пауза, а параллельность должна быть фиксированной. Это защищает сервис от собственной проверки и делает серии сравнимыми. Если используется тарификация по трафику, в отчёте укажите ожидаемый расход до запуска, чтобы тест не стал неожиданной докупкой.

Разделяйте задержку и пропускную способность. Маленький ответ показывает стоимость DNS, соединения, TLS и первого байта; файл 10 МБ сильнее отражает передачу между клиентом и проверочным сервером через выбранную прокси. Ни один результат не является универсальной скоростью интернета. Для сайта с множеством ресурсов отдельно измерьте реальный сценарий браузера, потому что повторное использование соединений и кэш меняют картину.

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

Типичные ошибки

Нельзя сравнивать Wi‑Fi утром с кабелем вечером, разные файлы или разные CDN-узлы. Не отключайте таймаут, пытаясь дождаться бесконечного ответа, и не запускайте десятки тяжёлых тестов подряд. Они расходуют трафик и сами создают очередь. Лучше ограниченная серия, пауза и повтор только аномальных значений.

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

Критерии внедрения и сопровождение

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

Через неделю после запуска проверьте, совпадают ли фактическая нагрузка, расходы и качество с тестом. Затем назначьте регулярный малый контроль и повторную проверку после обновления клиента, прокси-сервиса или сетевой схемы. Устаревшую инструкцию архивируйте вместе с датой и причиной замены, чтобы сотрудники не использовали две конфликтующие конфигурации.

Рабочий регламент

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

• Есть прямой контроль
• Файл и endpoint одинаковы
• Сохранены отдельные фазы
• Используется медиана серии
• Ошибки отделены от скорости
• Указано, какой участок маршрута измерен