要約

  • 2013年のW3C Performance Timeline勧告は、名前、種類、開始時刻、長さを持つ記録と、getEntriesByType() などの取得手段を定めた。
  • 2015年のLevel 2草案は PerformanceObserver を加え、ブラウザーが新しい記録を作ったときにコールバックへ知らせる仕組みを示した。2016年の候補勧告と現行文書がその配送を詳しく定める。

ニュースのトップページがもたつく。画像の到着か、スクリプトの処理か、編集部が挟んだ操作か。ブラウザーには時間の記録がある。2013年のW3C Performance Timeline勧告は、それを PerformanceEntry として整理した。札には名前、種類、開始時刻、長さがある。getEntries() や getEntriesByType() で、すでに引き出しへ入った札を読める。書類棚は立派だが、いつ開けるかは調査員任せだった。

一度読んでもページの仕事は続く。画像が届き、計測用の印が追加され、別の資源の記録が入る。そのたびにプログラムが引き出しを開ければ、まるで記録係の肩をたたいて「今、書いた？」と聞き続けることになる。記録係は書いた瞬間を知っている。用事のある札が入ったらベルを鳴らす方が、仕事場としては自然だ。

2015年9月のPerformance Timeline Level 2草案は、従来の読み出し例と新しい監視の例を並べた。作者は PerformanceObserver に処理関数を渡し、追う記録の種類を指定する。ブラウザーは該当する新しい測定ができたとき、まとめた札をコールバックへ届ける。調査が終われば監視を切れる。いつ新記録が生まれたかを知る側が、通知を引き受けた。

W3Cの公開履歴によれば、Level 2の初公開草案は2015年7月16日。2016年12月8日の候補勧告は、観察者の登録、対象の種類、処理関数への配送をさらに記した。時計の針が新しくなったという話ではない。時計が記録を知らせるようになり、調査員が引き出しの前に立ちっぱなしで済むようになった。

ベルを鳴らす条件は編集部が選ぶ。画像の遅れを調べるなら資源の記録に注目し、ある操作のもたつきを追うなら作者の印を置く。プラットフォームは共通の札と届け方を定める。どの遅れを読者の不満と結びつけるかはサイトの仕事だ。すべての札を集めるだけなら、静かな編集部が騒がしい倉庫に変わる。

現行のPerformance Timeline仕様は、新しい記録に加え、種類によっては保存済みの記録を受け取る方法も扱う。種類別のバッファーには上限があり、落ちた記録の数も定義される。引き出しは無限ではない。監視を始める時刻と落ちた札を確かめてこそ、手元の数字を読む土台ができる。

ブラウザーは測って知らせる。ページの作者は、読者がどこで待ち、何を直すべきかを考える。ベルが鳴っただけで調査は終わらないが、時計に張りつく日々には区切りがついた。