ページが遅い。画像一枚ずつにストップウォッチを渡した

要約

• W3Cが2011年5月24日に公開した最初のResource Timing作業草案は、ページ全体ではなく画像など一つ一つの資源について、名前、開始点、DNS、接続、要求、応答の時刻を記録する構想を示した。
• 2017年3月30日のレベル1勧告候補は、資源の記録を性能タイムラインに置き、容量のあるバッファーと、外部資源の詳細を開くTiming-Allow-Originを定めた。

ページが遅い。主役の画像はスタイルシートを指さし、スタイルシートはスクリプトを指さす。スクリプトはサーバーの方角を見つめる。ページ全体の所要時間は読者が待ったことを教えるが、遅れた荷物の名前までは教えてくれない。Resource Timingは、到着した資源それぞれにストップウォッチを渡した。会議の空気は少し悪くなったが、議事録はずっと役に立つものになった。

W3Cが2011年5月24日に公開した最初のResource Timing作業草案は、ページの内部で生じる待ち時間に焦点を合わせた。例に使われたのは一枚の画像の取得時間である。文書のナビゲーションを一つの時計で測っても、ページを構成する画像、スタイル、スクリプトは別々に届く。見出しが現れた後で写真がやって来ることもある。総時間だけを眺めても、どの資源が列の最後に残ったかは分からない。

草案には、資源名、取得を始めた要素の種類、そして段階ごとの時刻が並ぶ。fetchStartからdomainLookupStart、connectStart、requestStart、responseStart、responseEndへと進めば、名前の解決、接続、要求、最初の応答、受信の終わりを追える。遅い画像を見つけた後で「ネットワークが悪い」と一括りにする必要はない。どの段階で時間を使ったかを確かめる入口ができた。

ただし、時計の針が同じ位置に重なることもある。ブラウザーが既存の接続を使ったり、キャッシュから資源を取り出したりすれば、通常の経路の一部は繰り返されない。値が同じだから計測が壊れた、と早合点するのは気が早い。初回訪問と二度目の訪問を比べるなら、キャッシュの状態も記録したい。時刻表が示すのは、その時の一回の取得である。

2017年3月30日のW3C Resource Timing Level 1勧告候補では、記録は性能タイムラインに収まっている。仕様の例はperformance.getEntriesByType('resource')で項目を取り出し、initiatorTypeがimgのものを選び、responseEndとstartTimeを比べる。画像を何枚も並べて、どれが遅れたかを調べられる。スタイルやスクリプトにも同じ考え方が使える。ページ全体に一枚の遅刻届を書かせる時代から、資源ごとの出勤簿へ移った。

出勤簿には用紙の枚数がある。2017年の文書は資源計測用のバッファーと、setResourceTimingBufferSize()やclearResourceTimings()を説明する。取得する資源が多いページでは、記録のための場所を使い切る。採集する側は何件残すか、いつ消すかを決めなければならない。後半の行が空白だから後半の資源は瞬間移動した、という解釈は通らない。単にノートが満杯だったかもしれない。

もう一つの判断は、ページの外にいる配信元が持つ。別のオリジンから来た画像の記録はタイムラインに現れ得るが、詳細な段階の時刻は標準では制限される。資源を配るサーバーはTiming-Allow-Origin応答ヘッダーで、指定したオリジンに詳しい値を見せることができる。画像を貼ったサイトが、配信元の内側の時計まで勝手にのぞける仕組みではない。時計の細かな目盛りを見せる鍵は、配信元の手にある。

したがって外部資源の空欄を読むときは慎重さが要る。項目に資源名と所要時間があっても、DNSや接続、応答の細部は閉じられている場合がある。ゼロに見える欄を「仕事がゼロミリ秒だった」と読むと、観測の境界を速度の記録にすり替えてしまう。配信元が許可を出せばより多くの段階が見える。出さなければ、ページ側は見えている情報で調査を進める。

2026年9月1日付のW3C勧告候補草案は、この資源ごとの見方を続け、初期の文書より多い属性と大きなバッファーを記す。2011年の作業草案、2017年の勧告候補、2026年の新しい草案を、一枚の固定された仕様として扱うと歴史を取り違える。変わらない核は、ブラウザーが資源の到着を標準的な形で書き留め、ページがその記録を調べられることだ。

一番長くかかった画像が、必ず一番先に直すべき画像とは限らない。画面の下の方にあって読者がまだ見ていなかったかもしれない。逆に、少しだけ速い別の資源が見出しの表示を止めていたかもしれない。Resource Timingは取得の履歴を渡す。画面の配置や読者が見た順番は、制作側が重ねて読む必要がある。画像を軽くするか、順番を変えるか、後で届けるかは、その後の判断だ。

「ページが遅い」は愚痴で終わる。「この画像の要求はここで待った。スタイルシートは接続を再利用した。外部の画像は詳細を開いていない」なら、手を動かす順番を話せる。ストップウォッチは修理工ではない。それでも主役の画像がスタイルシートに罪を着せるには、まず自分の時刻表を提出しなければならなくなった。