dns-prefetchとpreconnect、そしてprefetchやprerenderとpreloadの併記

2014年10月より標準化作業が公開されたResource Hints仕様により、既存のrel=dns-prefetchrel=prefetch、そしてrel=prerenderは置き換えられる可能性がある。この置き換えが起こる可能性は決して高くはなさそうなので、実装されているもののままでも構わないと思うが、link要素のrel属性は複数の値を取ることができるので、同時指定しても良い。

rel=dns-prefetchrel=preconnectと完全に対応しているので、そのまま追加してやるだけになる。

<link
  href="//example.com"
  rel="preconnect dns-prefetch">

rel=prefetchrel=prerenderはResource Hints仕様ではrel=preloadに統合される。事前にレンダリングまでするかどうかはloadpolicy属性を併用することで制御する。

<link
  href="http://example.com/fetch"
  loadpolicy="next inert"
  rel="preload prefetch">
<link
  href="http://example.com/render"
  loadpolicy="next"
  rel="preload prerender">

rel=preloadはデフォルトで事前レンダリングを行うように支持するということになっており、それを無効にするためにはloadpolicy属性で不活性やサボるなどという意味を持つinertを指定する。つまりrel=prefetchと同じ挙動にしたい場合はinertを追加するということになる。

rel=preloadでは他にpr属性を使って読み込みのプライオリティーを、as属性を使って読み込むリソースの形式を指定することもできるようになっている。特にウェブアプリではその動線の予測しやすさから、事前読み込みを駆使することになると思うので、pr属性を使ってうまくプライオリティーを制御することでより効果的なプリロードを行えることだろう。対してas属性での形式の指定は、画像やフォントの場合は択一式で提供することも多いはずなので、html以外を使う機会はあまりなさそうだ。


あとは実際にうまく機能してくれるかどうかということになる。

rel=dns-prefetchrel=preconnectの併記は、Firefox 38及びChrome 43、Internet Explorer 11でちゃんと名前解決を行っているらしいことが確認できた。

rel=prefetchrel=prerenderの両方に対応しているChrome 43とInternet Explorer 11ではどちらの併記方法もうまく動いているらしきことは確認できた。Firefox 38でもrel=prefetchの方の併記は問題ないようだった。


速やかにrel=preconnectrel=preloadへと移行されるかというと大きく疑問が残る。Resource Hints仕様が現状の実装に比べて大きく強化されていることもそうだが、実装の足並みがバラバラで各自が制限や拡張を行っていることや、プリフェッチ系の機能への根強い抵抗があることもある。少なくともマルチ・プロセス化したFirefoxがrel=prerender相当の機能を実装するくらいになるまではどうなるかの予想は難しいだろう。

ともあれ現時点では併記しておくというのは悪くない。運良くResource Hints仕様へ揃う可能性もなくはないからだ。