リソースヒントを使用したパフォーマンスの最適化

公開: 2022-03-10

簡単な要約↬ユーザーが実際に行う前に、ユーザーが行う可能性のあることを予測できる場合、多くのパフォーマンスの最適化を行うことができます。リソースヒントは、Web開発者がブラウザーをユーザーの一歩先に進め、ページを高速に保つのに役立つ、シンプルで効果的な方法です。

最新のWebブラウザーは、ユーザーが次に何をする可能性があるかを推測することにより、ページの読み込みパフォーマンスを向上させるためにあらゆる種類の手法を使用しています。ただし、ブラウザは私たちのサイトやアプリケーション全体についてはあまり知りません。多くの場合、ユーザーが行う可能性のあることについての最良の洞察は、開発者である私たちから得られます。

フォトアルバムのようなページ付けされたコンテンツの例を見てみましょう。ユーザーがアルバム内の写真を見ている場合、「次へ」リンクをクリックしてアルバム内の次の画像を表示する可能性が非常に高いことがわかっています。ただし、ブラウザは、ページ上のすべてのリンクのうち、ユーザーがクリックする可能性が最も高いリンクを実際には認識していません。ブラウザにとって、これらのリンクはすべて同じ重みを持っています。

ブラウザがユーザーが次に進む場所を何らかの方法で認識し、ユーザーがリンクをクリックしたときにページの読み込みがはるかに高速になるように、次のページを事前に取得できるとしたらどうでしょうか。それが原則としてリソースヒントです。これらは、開発者が将来何が起こる可能性があるかをブラウザーに通知する方法であり、ブラウザーはそれをリソースのロード方法の選択に織り込むことができます。

これらのリソースヒントはすべて、HTMLドキュメントの<head>で見つけるのに慣れている<link>要素のrel属性を使用します。この記事では、リソースヒントの主な種類と、それらをページでいつどこで使用できるかを見ていきます。最後に、小さくて微妙なヒントから大きな銃に行きます。

ジャンプした後もっと！以下を読み続けてください↓

DNSプリフェッチ

DNSルックアップは、 example.comのような人に優しいドメイン名を、リソースをフェッチするために実際に必要な123.54.92.4のようなマシンに優しいIPアドレスに変換するプロセスです。

ブラウザのアドレスバーにURLを入力したり、ページ内のリンクをたどったり、別のドメインからの画像などのリソースを読み込んだりするたびに、ブラウザはDNSルックアップを実行して、リソースを保持しているサーバーを見つける必要があります。要求されました。外部リソースがたくさんある忙しいページ（おそらく、広告やトラッカーがたくさんあるニュースWebサイトなど）の場合、ページごとに数十のDNSルックアップが必要になることがあります。

ブラウザはこれらのルックアップの結果をキャッシュしますが、遅くなる可能性があります。パフォーマンス最適化手法の1つは、リソースをより少ないドメインに編成することにより、必要なDNSルックアップの数を減らすことです。それが不可能な場合は、 dns-prefetchリソースヒントを使用して検索する必要のあるドメインについてブラウザに警告できます。

 <link rel="dns-prefetch" href="https://images.example.com">

ブラウザがこのヒントに遭遇すると、まだどのように使用されるかわからなくても、 images.example.comドメイン名の解決をできるだけ早く開始できます。これにより、ブラウザはゲームを先取りし、より多くの作業を並行して実行できるようになり、全体的な読み込み時間が短縮されます。

いつ`dns-prefetch`を使用する必要がありますか？

ページが別のドメインのリソースを使用する場合は、 dns-prefetchを使用して、ブラウザをすぐに開始できます。ブラウザのサポートは本当に素晴らしいですが、ブラウザがそれをサポートしていなくても害はありません—プリフェッチは起こりません。

使用していないドメインをプリフェッチしないでください。多数のドメインをプリフェッチしたい場合は、それらのドメインがすべて必要な理由と、その数を減らすために何かできるかどうかを確認することをお勧めします。

事前接続

DNSプリフェッチからの一歩は、サーバーへのプリコネクトです。リソースをホストしているサーバーへの接続を確立するには、いくつかの手順を実行します。

DNSルックアップ（先ほど説明したように）。
TCPハンドシェイク
接続を作成するためのブラウザとサーバー間の簡単な「会話」。
HTTPSサイトでのTLSネゴシエーション
これにより、証明書情報が有効であり、接続に対して正しいことが確認されます。

これは通常、サーバーごとに1回発生し、貴重な時間を要します。特に、サーバーがブラウザーから非常に離れていて、ネットワークの遅延が大きい場合はそうです。（これは、グローバルに分散されたCDNが本当に役立つ場所です！）DNSのプリフェッチは、ブラウザーが何が来るかを確認する前にゲームを先取りするのに役立つのと同じように、サーバーに事前接続することで、ブラウザーがその部分に到達したときに確実になります。リソースが必要なページでは、接続を確立するための遅い作業がすでに行われており、回線は開いており、準備ができています。

 <link rel="preconnect" href="https://scripts.example.com">

いつ`preconnect`を使用する必要がありますか？

繰り返しになりますが、ブラウザのサポートは強力であり、ブラウザが事前接続をサポートしていなくても害はありません。結果は以前と同じになります。リソースにアクセスすることが確実で、先に進みたい場合は、事前接続の使用を検討してください。

事前接続してから接続を使用しないように注意してください。これにより、ページの速度が低下し、接続するサーバー上の少量のリソースも占有されます。

次のページのプリフェッチ

これまで見てきた2つのヒントは、主に、読み込まれるページ内のリソースに焦点を当てています。たとえば、ブラウザが画像、スクリプト、フォントを先に進めるのに役立つ場合があります。次のいくつかのヒントは、ナビゲーションと、現在読み込まれているページの後にユーザーが移動する可能性のある場所の予測に関するものです。

これらの最初のものはプリフェッチであり、そのリンクタグは次のようになります。

 <link rel="prefetch" href="https://example.com/news/?page=2" as="document">

これは、ブラウザに先に進んでバックグラウンドでページをフェッチできることを通知し、要求されたときにすぐに使用できるようにします。ユーザーが次にナビゲートすると思われる場所を先取りする必要があるため、ここにはちょっとした賭けがあります。正しく理解すれば、次のページが非常に速く読み込まれるように見える場合があります。間違えると、使用されないものをダウンロードするのに時間とリソースを浪費してしまいます。ユーザーが限られた携帯電話プランのように従量制の接続を使用している場合、実際には実際の費用がかかる可能性があります。

プリフェッチが行われると、ブラウザはDNSルックアップを実行し、前の2種類のヒントで見たサーバー接続を確立しますが、さらに一歩進んで実際にファイルを要求してダウンロードします。ただし、その時点で停止し、ファイルは解析または実行されず、現在のページに適用されることはありません。彼らはただ要求され、準備ができています。

プリフェッチは、ブラウザのキャッシュにファイルを追加するようなものだと考えるかもしれません。ユーザーがリンクをクリックしたときにサーバーにアクセスしてダウンロードする代わりに、ファイルをメモリから引き出して、はるかに高速に使用できます。

`as`属性

上記の例では、 as属性をas="document"に設定していることがわかります。これは、フェッチしているものをドキュメント（つまり、Webページ）として処理する必要があることをブラウザに通知するオプションの属性です。これにより、ブラウザは、新しいページへのリンクをたどった場合と同じ種類のリクエストヘッダーとセキュリティポリシーを設定できます。

ブラウザがさまざまなタイプのプリフェッチを適切な方法で処理できるようにすることで、 as属性に可能な値がたくさんあります。

`as`の値	リソースの種類
`audio`	サウンドと音楽ファイル
`video`	ビデオ
`Track`	ビデオまたはオーディオのWebVTTトラック
`script`	JavaScriptファイル
`style`	CSSスタイルシート
`font`	Webフォント
`image`	画像
`fetch`	XHRおよびFetchAPIリクエスト
`worker`	Webワーカー
`embed`	マルチメディア`<embed>`リクエスト
`object`	マルチメディア`<object>`リクエスト
`document`	ウェブページ

as属性でリソースタイプを指定するために使用できるさまざまな値。

いつ`prefetch`を使用する必要がありますか？

繰り返しますが、 prefetchは優れたブラウザサポートを備えています。ナビゲーションの高速化がユーザーエクスペリエンスにプラスの影響を与えると思われる場合は、ユーザーがサイトをフォローする可能性が十分にある場合に使用する必要があります。これは、使用されていないリソースをフェッチすることによってリソースを浪費するリスクと比較検討する必要があります。

次のページの事前レンダリング

prefetchを使用すると、ブラウザがバックグラウンドでファイルをダウンロードしてすぐに使用できるようになることを確認しましたが、その時点ではそれ以上何も行われていないことにも注意してください。事前レンダリングはさらに一歩進んでファイルを実行し、実際にページを表示することを除いて、ページを表示するために必要なほとんどすべての作業を実行します。

これには、JavaScriptファイルや画像などのサブリソースのリソースの解析と、それらのプリフェッチも含まれる場合があります。

 <link rel="prerender" href="https://example.com/news/?page=2">

これにより、次のページの読み込みが瞬時に行われるようになり、ブラウザの戻るボタンを押したときに表示されるような、きびきびとした読み込みパフォーマンスが得られます。ただし、ここでは、ファイルの要求とダウンロードに時間を費やすだけでなく、JavaScriptなどと一緒にファイルを実行するため、ギャンブルはさらに大きくなります。これにより、メモリとCPU（したがってバッテリー）が使い果たされる可能性があり、ユーザーがページを要求しなくなった場合にメリットが得られなくなります。

いつ`prerender`を使用する必要がありますか？

prerenderのブラウザサポートは現在非常に制限されており、実際にはChromeと古いIE（Edgeではない）のみがオプションのサポートを提供しています。特にChromeをターゲットにしている場合を除いて、これによりその有用性が制限される可能性があります。繰り返しになりますが、ユーザーにはメリットが表示されないため、「害なし、ファウルなし」の場合ですが、そうでない場合でも問題は発生しません。

リソースのヒントを活用する

<link>タグを使用してHTMLドキュメントの<head>でリソースヒントを使用する方法については、すでに説明しました。これはおそらく最も便利な方法ですが、 Link: HTTPヘッダーを使用して同じことを実現することもできます。

たとえば、HTTPヘッダーを使用してプリフェッチするには、次のようにします。

 Link: <https://example.com/logo.png>; rel=prefetch; as=image;

また、JavaScriptを使用して、おそらくインタラクションの使用に応じて、リソースヒントを動的に適用することもできます。 W3C仕様書の例を使用するには：

 var hint = document.createElement("link"); hint.rel = "prefetch"; hint.as = "document"; hint.href = "/article/part3.html"; document.head.appendChild(hint);

これにより、ユーザーがページをどのように操作したかに基づいて、ユーザーが次にナビゲートする可能性のある場所を予測しやすくなる可能性があるため、いくつかの興味深い可能性が開かれます。

注意事項

DNSを解決するという最も軽いタッチから、バックグラウンドですぐに使用できる完全なページをレンダリングするまで、リソースをプリロードする4つの段階的により積極的な方法を見てきました。これらのヒントはまさにそれであることを覚えておくことが重要です。これらは、ブラウザがパフォーマンスを最適化する方法のヒントです。それらはディレクティブではありません。ブラウザは私たちの提案を受け入れ、応答方法を決定する際に最善の判断を下すことができます。

これは、ビジー状態のデバイスや過度に拡張されたデバイスでは、ブラウザがヒントにまったく応答しないことを意味する場合があります。ブラウザが従量制接続を使用していることを認識している場合、たとえば、DNSをプリフェッチする可能性がありますが、リソース全体をプリフェッチすることはできません。メモリが少ない場合、ブラウザは、現在のページがオフロードされるまで、次のページをフェッチする価値がないと再び判断する可能性があります。

現実には、デスクトップブラウザーでは、開発者が提案するようにヒントはすべて従う可能性がありますが、すべての場合においてそれはブラウザー次第であることに注意してください。

メンテナンスの重要性

Webを数年以上使用している場合は、ページ上の何かが見えない場合、それが無視されることがよくあるという事実に精通しているでしょう。非表示のメタデータ（ページの説明など）は、この良い例です。サイトの世話をしている人がデータをすぐに見ることができない場合、それは簡単に無視されて時代遅れになる可能性があります。

これは、リソースのヒントを伴う実際のリスクです。コードは隠されており、使用中にほとんど検出されないため、ページを変更したり、リソースのヒントを更新しなかったりするのは非常に簡単です。たとえば、使用していないページをプリフェッチすると、サイトのパフォーマンスを向上させるために配置したツールが積極的にページに悪影響を及ぼしていることを意味します。したがって、リソースのヒントを最新の状態に保つための適切な手順を用意することが、非常に重要になります。

資力

「リソースヒントの仕様」、W3C
「プリフェッチで次のページのナビゲーションを高速化」、Addy Osmani