Summary

  • Первый открытый проект Navigation Timing W3C опубликовал 26 октября 2010 года: скрипт страницы начинает отсчёт после того, как часть пути уже пройдена.
  • Рекомендация от 17 декабря 2012 года закрепила отметки навигации, поиска имени, соединения, ответа и готовности документа. Сайт сам решает, какие поездки сравнивать и что исправлять.

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

В первом открытом проекте от 26 октября 2010 года W3C показал изъян на простом примере. Код в начале документа запоминает время выполнения и вычитает его из времени события загрузки. Однако документ со скриптом ещё надо получить. Пока код не заработал, браузер мог найти адрес, установить соединение и дождаться ответа. Для пользователя эти секунды были настоящими; для скриптового секундомера они будто не существовали.

В проекте предложили обратиться к свидетелю, присутствовавшему при отправлении. Браузер отмечал navigationStart, а через performance.timing отдавал странице и другие моменты пути. Разница между окончанием загрузки и началом навигации считалась обычным вычитанием. Главное было не в арифметике, а в праве на исходную точку. Скрипт не мог задним числом увидеть то, что случилось до его появления. Браузер мог.

В счёте появлялись отдельные строки. fetchStart обозначал начало получения ресурса или проверки кэша. domainLookupStart и domainLookupEnd ограничивали поиск имени; connectStart и connectEnd — установление соединения. requestStart, responseStart и responseEnd различали запрос, первый байт ответа и завершение получения документа. Дальше шли стадии готовности DOM и событие загрузки. Фраза «сайт тормозит» распадалась на проверяемые версии: долго искали адрес, долго соединялись, ждали сервер или разбирали уже доставленный документ?

Кандидатская редакция от 2 июня 2011 года стала следующей остановкой. Рекомендация от 17 декабря 2012 года закрепила интерфейс PerformanceTiming и правила для его полей. История публикаций W3C показывает маршрут от проекта 2010 года через кандидатские версии 2011-го к итоговому тексту. Это не внезапное озарение одного вечера: над счётом работали, чтобы разные участники одинаково понимали его строки.

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

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

Были и строки, намеренно закрытые для читателя. Когда перенаправление пересекало границу разных источников, подробные отметки перенаправления обнулялись. Новая страница не получала возможность подсматривать по времени за предыдущим сайтом. Текст 2012 года отметил ещё одну тонкость: страницы разных авторов под одним именем хоста могут считаться одним источником, хотя социально это разные хозяева. Измерение полезно ровно настолько, насколько ясны границы его раскрытия.

Navigation Timing не отправлял отчёты и не ускорял страницы автоматически. Ещё проект 2010 года оставлял сбор, хранение и представление данных приложению. Итоговый документ отдельно говорил, что интерфейс сам по себе не предназначен для соревнования браузеров. Одна загрузка зависит от устройства, сети, кэша и кода сайта. Получить счёт — это начало расследования, а не доказательство того, что лифт уже починен.

Зато исчезала удобная расплывчатость. Команда могла выяснить, пришёл ли первый байт поздно или документ долго становился интерактивным после ответа. Браузер поделился временем, которого страница прежде не видела. У стойки регистрации больше нельзя было объяснить весь долгий путь работой портье или, наоборот, целиком свалить его на лифт.