摘要

  • W3C 2013 年的 Performance Timeline 推荐标准规定了带名称、类型、起始时间和持续时间的 PerformanceEntry，作者可用 getEntriesByType() 等方法查看已保存的记录。
  • 2015 年 Level 2 草案加入 PerformanceObserver：浏览器记录新指标时，把符合条件的条目交给回调。2016 年候选推荐标准与现行文本进一步明确通知和缓冲区规则。

“首页太慢了”很容易说出口，查明慢在哪里却像调查一桩没有目击者的案子。浏览器保存着线索：导航、资源加载、作者设置的标记。按照 W3C 2013 年的 Performance Timeline 推荐标准，每条线索都有名称、类型、起始时刻和时长。网页代码可以调用 getEntries() 或 getEntriesByType()，拿到已经记录的条目。证物柜建好了，调查员得自己记得去开柜门。

第一次查看之后，页面还在继续工作。图片到达了，脚本完成了一个步骤，新的标记又写进去。代码可以每隔一会儿再翻一次柜子，盼着刚好看到需要的卡片。可浏览器正是写卡片的人，它最清楚何时放进了新证物。让记录员在写完后按铃，比派人一遍遍去问“有新东西吗”像样得多。

2015 年 9 月的 Performance Timeline Level 2 草案把两种工作方式并排摆出：先有读取已存条目的例子，再有 PerformanceObserver。作者创建观察者，交给它回调函数，指定要看的条目类型。浏览器记录到符合条件的新指标时，把条目列表送来；作者可以成批处理，也可以在工作结束后断开观察。通知的时机回到了掌握计时事实的浏览器手里。

W3C 发布史把 Level 2 首份公开草案定在 2015 年 7 月 16 日。2016 年 12 月 8 日的候选推荐标准进一步写明观察者的注册、条目类型与回调交付。这是从“自己去查”到“新事发生时有人喊你”的变化。新闻室没有多出一块更快的秒表，只是终于不用盯着表盘等它动。

观察者仍需要明确的任务。如果编辑怀疑图片拖慢首页，可以盯资源条目；如果一个阅读动作卡顿，可在关键阶段放置作者标记，再看对应记录。浏览器提供通用的条目形式和通知路径，网站决定哪些信号值得追、如何解释它们。铃声再响，没人提出问题，也只会让办公室更吵。

现行 Performance Timeline 规范还描述按类型存放条目的缓冲区、可选的旧条目读取，以及缓冲区满时的丢失计数。证物柜并非无底洞。调查页面性能时，得知道观察从何时开始、柜里可能漏掉多少卡片，然后再结合收到的记录判断。一个空列表不足以给读者的等待盖章。

这套机制把报时的职责交给记录者，把解释的职责留给页面作者。浏览器知道指标何时出现，编辑部知道读者为什么会在一张迟到的照片前失去耐心。前者按铃，后者决定该修哪扇门。