要約

  • W3Cの2013年Resource Priorities草案は、lazyloadやpostponeなどを使い、ダウンロードの優先度について作者の意図をブラウザーに伝えようとした。2014年の文書は、この仕様を放棄したと明記している。
  • 後年のWICG Priority Hints報告書が古くなった理由は別にある。関係する規則がHTMLとFetchに取り込まれた。現行のfetchpriorityは同じ取得先種別の資源間でhigh、low、autoを示し、ブラウザーの内部優先度は別に残る。

ページを作る人は、どの画像が読者に最初に届くべきかを知っている。一方、通信の混雑や端末の負荷をその場で引き受けるのはブラウザーだ。両者が持つ情報は重ならない。HTMLに先に現れたファイルが、読者にとって先に必要なファイルとは限らない。このずれが、優先度をめぐる仕様を生んだ。

2013年10月29日のW3C初公開作業草案はResource Prioritiesを掲げた。lazyloadは資源が競合する場面で優先度を下げる手掛かり、postponeは要素が表示領域に近づくまで取得を遅らせる考え方として説明され、CSSの仕組みも検討された。導入部は文書順の取得が体感上の価値と一致しない問題を挙げる。草案が示したのは設計の意図であり、当時の実装普及率を示す数字ではない。

ところが、2014年10月23日のW3C作業部会ノートは、この仕様の保守をやめて放棄したと明言した。参照先としてResource Hintsを勧めてもいる。2014年版にlazyloadの説明は残るが、2013年版のpostpone節は消えた。現在のfetchpriorityを昔の属性の改名版として読むと、この記録にない系譜を作ってしまう。

別の経路をたどったのが2023年2月22日のWICG Priority Hints報告書だ。開発者が取得時の相対的な優先度をブラウザーへ知らせる仕組みを記した。この報告書も現在は「obsolete」と表示される。ただし理由は、関連部分がHTMLとFetchの中核仕様へ移されたためだ。一方は開発が止まり、もう一方は内容が移籍した。同じ古い看板を見ても、建物の中で何が起きたかは違う。

HTML Living Standardにあるfetchpriorityの状態はhigh、low、autoの三つ。比較の対象は同じdestinationの資源で、指定がない場合や不正な値はautoになる。「高」と書けばあらゆる通信に割り込める、という仕組みではない。たとえば記事の主画像と飾りの画像を見分けるための、限定された合図だ。

Fetch Living Standardは要求にhigh、low、autoのpriorityを設け、これとは別に、実装側が定める形を取り得るinternal priorityを置く。ここに設計の肝がある。編集者は記事の重心を知り、ブラウザーは通信の現場を知る。ページが一枚のメモを差し出しても、順番表そのものはブラウザーが持つ。

どのブラウザーで何ミリ秒速くなるかは、これらの仕様文書だけからは出てこない。主画像に高いヒントを付ける意味は、作者の知識をちょうどよく伝えることにある。片端から全てを高くすれば、メモの意味は薄れる。ネットワークが混むほど、本当に急ぐ一件を選ぶ腕が試される。