要約

  • 2014年10月のW3C初公開草案は、必要なリソースの完全なURLがまだ分からなくても、発信元が分かっていれば preconnect でDNS、TCP、場合によってTLSの準備を始められると述べた。
  • 後の草案では dns-prefetch、preconnect、prefetch、prerender を区別した。ヒントを見たブラウザーは接続を全部進めても一部だけ進めても、状況に応じて見送ってもよい。

写真集のページには次の画像を置くサーバーが分かっている。しかし、読者が次に選ぶ写真までは分からない。ファイルを当てずっぽうに取ってくるより、サーバーとの挨拶だけ先に済ませておく手がある。URLが決まるまでの短い隙間を使う。それが preconnect の狙いだった。レストランの場所が分かれば、注文が未定でも席だけ確認できる。

2014年10月21日のW3C初公開草案は、ページの作者やサーバーがブラウザーに発信元を知らせる方法を提案した。早められる作業としてDNSでの名前解決、TCPの握手、必要に応じたTLSの交渉を挙げる。同じ初稿には preload もあったが、こちらは特定のリソースを取る話だ。発信元と話せる状態になることと、どのファイルか分からないまま中身を持ち帰ることは違う。

2017年5月4日の作業草案では四つの関係が整理された。dns-prefetch は名前解決を先に頼む。preconnect は発信元への接続を準備する。prefetch は次の画面で使うかもしれないリソースを取得する。prerender は将来の文書の準備に踏み込むことがある。作業量も予想の深さも違う。席の予約と厨房の仕込みを同じ「先読み」で片づけると、費用の差が見えなくなる。

2019年6月27日の草案は、リソースのURLがページの組み立て中に決まる場面を説明する。それでも取得先の発信元は早くから分かることがある。接続の交渉をこの間に始めれば、URLが決まった瞬間の待ち時間を減らせる。予想するのは写真そのものではなく、写真を持つ相手だ。

もっとも、ブラウザーはすべての相手に電話をかける義務を負わない。2020年10月5日の作業草案は、完全な接続、一部だけの準備、実行しない判断をブラウザーに認める。発信元あたりの接続本数も、通信方式、端末の余裕、ネットワークの状態、全体の制限を見て決める。ページが空席を十卓求めても、ブラウザーは店全体を貸し切らない。

使わなかった早期接続には費用が残る。多すぎる予想は、いま必要な読み込みと回線や計算資源を奪い合う。2020年の文書は、残っている preconnect の作業が文書のloadイベントを遅らせてはならないとも定めた。明日来るかもしれない客のために、いまの客を入口で待たせないということだ。

W3Cの公開履歴には2014年の初公開草案から後の作業草案が並ぶ。最初に並んだ preconnect と preload の話は、名前解決、接続、リソース取得、文書準備を分ける形へ広がった。どれも当時の草案である。変わらない中心は、ページの先読みをブラウザーの判断材料にするという配役だ。料理が決まる前でも、電話を一本入れる価値がある場合はある。