Summary

  • W3C 在 2010 年 10 月 26 日发布 Navigation Timing 首份公开草案，指出网页脚本启动的计时器会漏掉脚本抵达之前的等待。
  • 2012 年 12 月 17 日的推荐标准用浏览器记录的时间点，把导航、DNS、连接、响应和 DOM 进程串成一张明细；网站仍须自己决定怎样采集、分析和改进。

客人冲进旅馆大堂，已经等过车、找过路、排过队。前台这才按下秒表，三十秒后递来房卡，宣布入住速度一流。客人当然可以赞美前台手快，但他不会因此忘记刚才在雨里站的半小时。早期网页用自己脚本测加载时间，问题就出在这里：秒表醒来时，旅程已经走了一截。

W3C 的 2010 年 10 月 26 日首份公开草案把这个漏洞写得很直白。把 JavaScript 放在页面头部，记下执行时间，再等加载事件发生，二者相减确实得到一个数字。可浏览器在执行这段脚本前，已经可能发出请求、建立连接、等服务器送来页面。读者经历了这些时间，脚本却没有出生证明可以补记。

草案的办法，是让一直在场的浏览器记账。navigationStart标出导航的起点，随后的一系列属性给出各阶段的时间。页面可以读取performance.timing.navigationStart，再和加载结束的时间相比。减法并不高深；真正有价值的是起点终于放在读者开始等候的地方，而不是放在脚本获准发言的地方。

这张单据不是只印总价。fetchStart对应开始取得资源或查询缓存；domainLookupStart和domainLookupEnd框住域名查询；connectStart与connectEnd记录连接；requestStart、responseStart和responseEnd把请求与响应拆开。随后还有文档开始加载、变得可交互、完成 DOM 处理以及触发加载事件的时间点。团队于是能问出具体问题：是地址找得慢，连接迟迟没建好，首字节晚到，还是页面自己在拿到文档后忙得不可开交？

2011 年 6 月 2 日的候选推荐文本表明，这些时间点正在进入更正式的标准程序。2012 年 12 月 17 日的 W3C 推荐标准确立了熟悉的PerformanceTiming接口和相应处理规则。W3C 的出版记录把 2010 年草案、2011 年候选阶段和 2012 年定稿连在一起。收据要能用于争议，先得让所有人同意每一行究竟算什么。

一些行看起来会“没花钱”。如果浏览器复用已有连接，就没有新的建连过程可计；从缓存取到文档，部分网络阶段的时间点也会重合。看到两个相等的数就喊“计时器坏了”，相当于客人明明坐着同一辆车，却硬要旅馆再开一张出租车票。标准把复用和缓存如何体现在字段里写清楚，避免把正常优化当成事故。

连钟表本身也要可靠。2012 年文本规定，导航过程中的计时应以单调时钟为基础，系统时钟被拨快拨慢，都不该让后来发生的事情在账面上跑到前面去。若账单写着“电梯抵达：14:02；电梯出发：14:05”，再漂亮的性能图表也只会引来白眼。测量的可信度往往藏在这种不起眼的规则里。

还有几行被有意留白。重定向若跨越不同来源，详细的重定向时间会归零，避免目的页面借计时信息窥探另一站点的行程。推荐标准同时提醒：同一主机名下不同作者的页面，在浏览器眼里可能仍属于同一来源；技术边界不总与内容归属一致。提供细节和限制细节，是同一套接口的两面。

Navigation Timing 也没有替网站自动采集样本、上传统计或修好慢页面。2010 年草案已说清楚，数据的收集、存储和报告由应用自行决定；2012 年文本还提醒，接口本身不是拿来给浏览器品牌排名的通用跑分器。一趟旅程牵涉设备、缓存、网络和页面。能看见时间分布，才有机会诊断；拿着收据就宣布电梯修好了，还是太乐观。

真正改变的是谁掌握起点。浏览器从导航开始便在现场，网页脚本直到后来才赶到。标准让前者把亲眼见到的时间交给后者，并使用共同的字段。此后，开发者可以少说一句“感觉有点慢”，多问一句“时间究竟花在哪个柜台”。