Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

Service Worker と Cache Storage API

Jeff Posnick

ネットワークの信頼性を確保するための戦いに巻き込まれています。ブラウザの HTTP キャッシュは最初の防御線ですが、すでに説明したように、以前にアクセスしたバージョン付き URL を読み込む場合にのみ有効です。HTTP キャッシュだけでは不十分です。

幸いなことに、状況を好転させるのに役立つ 2 つの新しいツール、Service Worker と Cache Storage API があります。これらは一緒に使用されることが多いため、両方を同時に学習することをおすすめします。

Service Worker

サービスワーカーはブラウザに組み込まれており、作成する必要がある追加の JavaScript コードによって制御されます。これは、実際のウェブアプリケーションを構成する他のファイルとともにデプロイします。

サービスワーカーには、いくつかの特別な機能があります。主な役割は、ウェブアプリが送信リクエストを行うのを辛抱強く待ち、リクエストをインターセプトして処理することです。このインターセプトされたリクエストを Service Worker がどのように処理するかは、デベロッパー次第です。

リクエストによっては、サービスワーカーがまったく存在しない場合と同様に、リクエストをネットワークに継続できるようにすることが最善の方法です。

ただし、他のリクエストでは、ブラウザの HTTP キャッシュよりも柔軟な機能を利用して、ネットワークを気にすることなく、信頼性の高い高速なレスポンスを返すことができます。これには、もう 1 つのパズルのピースである Cache Storage API を使用する必要があります。

Cache Storage API

Browser Support

Source

Cache Storage API を使用すると、デベロッパーはキャッシュの内容を完全に制御できるため、まったく新しい可能性が広がります。Cache Storage API は、HTTP ヘッダーとブラウザに組み込まれたヒューリスティックの組み合わせに依存するのではなく、コードドリブンなキャッシュ保存アプローチを公開します。Cache Storage API は、サービスワーカーの 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 キャッシュに追加すると、ブラウザは追加のネットワークリクエストを回避します。逆に、Cache-Control ヘッダーの構成が不適切で、バージョニングされていない URL に有効期間の長いキャッシュを指定している場合、古いコンテンツを Cache Storage API に追加することで、状況が悪化する可能性があります。Cache Storage API を効果的に使用するには、HTTP キャッシュの動作を整理しておく必要があります。

この新しい 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 構文について理解しておく必要があります。

コードをデプロイしないでください。

サービスワーカーと Cache Storage API は、重要な基盤を提供し、そのまま使用できますが、実際には下位レベルのビルディングブロックであり、多くのエッジケースと「落とし穴」があります。これらの API の難しい部分をスムーズにし、本番環境に対応した Service Worker の構築に必要なすべてを提供する、より高度なツールがいくつかあります。次のガイドでは、そのようなツールの 1 つである Workbox について説明します。