ネットワークの信頼性に悩まされています。ブラウザの HTTP キャッシュは防御の最前線ですが、すでに説明したように、実際に効果があるのは、バージョニングされた URL を読み込むときだけです。HTTP キャッシュだけでは不十分です
幸いなことに、状況を変えるために Service Worker と Cache Storage API の 2 つの新しいツールを利用できます。これらは一緒に使用されることが多いため、両方を同時に学ぶ価値があります。
Service Worker
Service Worker はブラウザに組み込まれており、デベロッパーが作成した追加の JavaScript コードで制御されます。これを、実際のウェブ アプリケーションを構成する他のファイルとともにデプロイします。
Service Worker には特殊な機能があります。とりわけ、ウェブアプリが送信リクエストを行うのを辛抱強く待ち、その後、リクエストをインターセプトして行動に移ります。インターセプトされたリクエストで Service Worker が行う処理は、ユーザーが自由に決めることができます。
リクエストによっては、Service Worker がまったく存在しない場合と同様に、リクエストをネットワーク上で続行できるようにすることが最善策である場合があります。
ただし、他のリクエストでは、ブラウザの HTTP キャッシュよりも柔軟な機能を利用して、ネットワークを気にすることなく、確実に高速なレスポンスを返すことができます。そのためには、もう一つの要素である Cache Storage API を使用します。
Cache Storage API
Cache Storage API を使用すると、キャッシュの内容を完全に制御できるため、まったく新しい可能性が広がります。Cache Storage API は、HTTP ヘッダーとブラウザの組み込みheuristicsの組み合わせに依存する代わりに、コード駆動型のキャッシュ アプローチを提供します。Cache Storage API は、Service Worker の JavaScript から呼び出す場合に特に便利です。
ちょっと待って... 他に検討すべきキャッシュがあるの？
おそらくは、「HTTP ヘッダーを構成する必要はあるか」、「HTTP キャッシュでは不可能だったこの新しいキャッシュではどうすればよいか」などと疑問に思うこともあるでしょう。これは自然な反応ですので、ご安心ください。
Cache Storage API の使用がわかっている場合でも、ウェブサーバーで Cache-Control ヘッダーを構成することをおすすめします。通常は、バージョニングされていない URL には Cache-Control: no-cache を設定し、ハッシュなどのバージョニング情報を含む URL には Cache-Control: max-age=31536000 を設定します。
Cache Storage API キャッシュにデータを入力するとき、ブラウザはデフォルトで HTTP キャッシュ内の既存のエントリをチェックし、見つかった場合はそれらのエントリを使用します。バージョニングされた URL を Cache Storage API キャッシュに追加すると、ブラウザは追加のネットワーク リクエストを回避します。その裏側は、バージョニングされていない URL に有効期間の長いキャッシュを指定するなど、正しく構成されていない Cache-Control ヘッダーを使用している場合、古いコンテンツを Cache Storage API に追加することで状況が悪化する可能性があります。HTTP キャッシュの動作を並べ替えることは、Cache Storage API を効果的に使用するための前提条件です。
この新しい API でできることは、「多い」という答えです。HTTP キャッシュだけでは難しい、または不可能な一般的な使用例には、次のようなものがあります。
- キャッシュに保存されたコンテンツに対して、「stale-while-revalidate」という「バックグラウンドでの更新」アプローチを使用します。
- キャッシュに保存するアセットの最大数に上限を設定し、上限に達したらアイテムを削除するカスタム有効期限ポリシーを実装します。
- 以前にキャッシュに保存されたネットワーク レスポンスと新しいネットワーク レスポンスを比較して、変更があるかどうかを確認し、データが実際に更新されたときにユーザーが（ボタンなどを使用して）コンテンツを更新できるようにします。
詳しくは、Cache API: クイックガイドをご覧ください。
API のナットとボルト
API の設計に関して、次の点に注意してください。
Requestオブジェクトは、これらのキャッシュの読み取りと書き込みを行うときに一意のキーとして使用されます。便宜上、実際のRequestオブジェクトの代わりに'https://example.com/index.html'のような URL 文字列をキーとして渡すことができます。そうすると、API が自動的に処理します。Responseオブジェクトは、これらのキャッシュの値として使用されます。- 特定の
ResponseのCache-Controlヘッダーは、データをキャッシュに保存するときに実質的に無視されます。有効期限や鮮度の自動チェックは組み込まれていません。キャッシュに保存されたアイテムは、コードによって明示的に削除されるまで保持されます。（キャッシュのメンテナンスを簡素化するためのライブラリがあります。これについては、このシリーズで後ほど説明します）。 LocalStorageなどの古い同期 API とは異なり、Cache Storage API のオペレーションはすべて非同期です。
簡単に説明: Promise と async/await
Service Worker と Cache Storage API は、非同期プログラミングのコンセプトを使用します。特に、非同期オペレーションの将来の結果を表すために Promise に大きく依存します。詳細に入る前に、Promise と関連する async/await 構文を理解しておく必要があります。
まだコードをデプロイしない
これらは重要な基盤であり、そのまま使用できますが、Service Worker と Cache Storage API はどちらも実質的に下位レベルの構成要素であり、多くのエッジケースや「落とし穴」があります。こうした API の難しい部分を取り除き、本番環境対応の Service Worker を構築するために必要なものをすべて提供できる、高レベルのツールもあります。次のガイドでは、そのようなツールの一つであるワークボックスについて説明します。