Summary

  • W3Cは2010年10月26日にNavigation Timingの最初の公開草案を出した。ページのスクリプトから計り始める方法では、それ以前の待ち時間が抜けることを出発点にしている。
  • 2012年12月17日の勧告は、ナビゲーションからDNS、接続、応答、DOMの処理までをブラウザーの時刻で示した。記録を集めて改善につなげる判断は、サイト側に残った。

ホテルに着いた客はくたびれている。道を探し、車を待ち、入口で並んだ末にようやくフロントへ。係員は客を見てから時計を押し、手早く鍵を渡して「お待たせ時間は二十秒です」と胸を張る。受付の仕事だけなら正しい。客が経験した道のりについては、ほとんど何も言っていない。

W3Cの2010年10月26日の最初の公開草案は、ウェブページにある同じ穴を示した。ページの先頭近くでJavaScriptが時刻を記録し、読み込みイベントまでの差を取る。得られる数字はスクリプトが動いてからの時間だ。そのスクリプトを含む文書が届くまでに要した時間は、時計の外にある。利用者には長い待ち時間が見えているのに、計測側はフロントに着いてからしか知らない。

そこで、ナビゲーションの始まりに立ち会ったブラウザーに記録を任せた。navigationStartが出発点となり、performance.timingから後の節目も読める。ページは読み込み完了時刻との差を取れば、以前より長い区間を測れる。引き算そのものは簡単だ。肝心なのは、ページ自身には遡って観察できない時間を、ブラウザーが共有することだった。

明細には行が並ぶ。fetchStartは取得やキャッシュ確認の始まり、domainLookupStartとdomainLookupEndは名前解決、connectStartとconnectEndは接続を挟む。requestStart、responseStart、responseEndは要求から文書の到着までを刻む。その後も文書の読み込み、操作可能になる時点、DOM関連イベント、読み込みイベントが続く。これで「遅いページ」という一塊の不満を、住所を調べる時間、入口を開ける時間、料理が出てくる時間、部屋を整える時間に分けられた。

2011年6月2日の候補勧告を経て、2012年12月17日の勧告はPerformanceTimingの項目と扱いを定めた。W3Cの刊行履歴には、2010年の草案から2011年の候補段階、2012年の正式文書までが載る。技術史を一夜の発明談にしないためにも、この段取りは大切だ。明細を証拠として使うには、どの行が何を意味するかを固める時間が要る。

ただし、すべての行に別々の時刻が現れるわけではない。既存の接続を再利用すれば、新しい接続の待ち時間はない。キャッシュから文書を取れば、ネットワークの工程も変わる。開始と終了が同じ時刻だから故障だ、と決めつければ、乗り換えをしていない客に乗り換え料金を請求するようなものだ。勧告は再利用やキャッシュを前提に各項目の値を定義した。

時計にも作法がある。2012年の文書は、ナビゲーション中にシステム時刻が調整されても経過時間が逆戻りしないよう、単調な時計を求めた。「エレベーターが出発する三分前に到着した」という記録では、どんな分析会議も進まない。測定に必要なのは細かい数字だけでなく、数字を信じられる約束事だ。

見せない行も決めている。異なるオリジンをまたいだリダイレクトでは、その詳しい時刻をゼロにする。行き先のページが、前のサイトの動きを時刻から探る手掛かりを得ないためだ。勧告は、同じホスト名の下に別々の作者がいる場合の注意も述べている。ブラウザーの「同じオリジン」と、人間が思う「別の持ち主」は、いつも一致するとは限らない。

最初の草案から、測定値を集め、保存し、報告する方法はアプリケーションに委ねられていた。ブラウザーが自動で改善案を出したり、遅いページを速くしたりはしない。勧告は、このインターフェースをブラウザー同士の単純な速度競争に使うものでもないと記す。ある訪問の時刻には端末、回線、キャッシュ、ページの状態が含まれる。数字を読むには、似た訪問を選び、目的を定める必要がある。

それでも、議論は変わった。以前なら「読み込みが遅い」で誰かのせいにできた。時刻の明細があれば、応答が遅かったのか、届いてから文書が操作可能になるまでが長かったのかを問える。ブラウザーは道のりを覚えていた。あとはホテル側が、フロントの時計だけを見つめるのをやめればよかった。