Service Worker の特長の 1 つは、Service Worker のインストール時にファイルをキャッシュに保存できることです。これは「プレキャッシュ」と呼ばれます。プレキャッシュにより、ネットワークを経由することなく、キャッシュに保存されたファイルをブラウザに配信できます。メインページ、スタイル、代替画像、重要なスクリプトなど、サイトに必要な重要なアセットはオフラインの場合でもプリキャッシュを使用します。
Workbox を使用する理由
事前キャッシュに Workbox を使用するかどうかは任意です。Service Worker のインストール時に重要なアセットを事前キャッシュに保存するためのコードを作成できます。Workbox を使用する主なメリットは、すぐに使用できるバージョン管理です。Workbox を使用して、事前キャッシュされたアセットを更新する場合、これらのファイルのバージョニングと更新を自分で管理するよりもはるかに少ない手間で済みます。
マニフェストを事前キャッシュする
プレキャッシュは、URL のリストと各 URL の関連するバージョニング情報によって行われます。これらをまとめてプリキャッシュ マニフェストと呼びます。マニフェストは、ウェブアプリの特定のバージョンのプリキャッシュに格納されるべきすべての状態の「信頼できる情報源」です。Workbox で使用される形式のプレキャッシュ マニフェストは次のようになります。
[{
url: 'app.abcd1234.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Service Worker がインストールされると、リストされた 3 つの URL のそれぞれに、キャッシュ ストレージに 3 つのキャッシュ エントリが作成されます。最初のアセットには、URL にすでにバージョニング情報が含まれています（app は実際のファイル名、.abcd1234 にはファイル拡張子 .js の直前にバージョニング情報が入ります）。Workbox のビルドツールでこれを検出し、リビジョン フィールドを除外できます。他の 2 つのアセットでは URL にバージョニング情報が含まれていないため、Workbox のビルドツールはローカル ファイルのコンテンツのハッシュを含む個別の revision フィールドを作成します。
事前キャッシュに保存されたリソースの提供
アセットをキャッシュに追加することは、事前にキャッシュする部分の一つにすぎません。アセットがキャッシュに保存されたら、送信リクエストに応答する必要があります。そのためには、Service Worker に fetch イベント リスナーが必要です。このリスナーは、事前キャッシュに保存された URL を確認し、プロセスのネットワークをバイパスして、キャッシュに保存されたレスポンスを確実に返します。Service Worker はキャッシュでレスポンスをチェックし、ネットワークより前に使用するため、これをキャッシュ ファースト戦略と呼びます。
効率的な更新
プリキャッシュ マニフェストは、予想されるキャッシュ状態を正確に表現します。マニフェスト内の URL とリビジョンの組み合わせが変更されると、Service Worker は、以前のキャッシュ エントリが有効でなくなっており、更新する必要があることを認識します。Service Worker の更新チェックの一環としてブラウザによって自動的に送信される 1 つのネットワーク リクエストのみを受け取り、更新する必要がある事前キャッシュ済み URL を判断します。
事前キャッシュに保存されたリソースの更新
ウェブアプリの新しいバージョンを徐々にリリースする場合は、以前に事前キャッシュした URL を最新の状態に保ち、新しいアセットを事前キャッシュし、古いエントリを削除する必要があります。サイトを再構築するたびに、完全なプリキャッシュ マニフェストを生成し続ける限り、そのマニフェストが任意の時点でのプリキャッシュ状態の信頼できる情報源として機能します。
新しいリビジョン フィールドを持つ既存の URL がある場合、またはマニフェストに URL が追加または削除された場合は、Service Worker に対して、install および activate イベント ハンドラの一部として更新を実行する必要があることを示します。たとえば、サイトに変更を加えて再ビルドした場合、最新のプリキャッシュ マニフェストに次のような変更が行われている可能性があります。
[{
url: 'app.ffaa4455.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
これらの変更のたびに、以前にキャッシュに保存されたエントリ（'offline.svg' と 'index.html'）の更新と新しい URL のキャッシュ（'app.ffaa4455.js'）のための新しいリクエスト、および使用されなくなった URL のクリーンアップ（'app.abcd1234.js'）のための新しいリクエストが必要であることを Service Worker に伝えます。
真の「アプリストア」のインストール エクスペリエンス
プレキャッシュのもう 1 つの利点は、「アプリストア」でのインストール以外では実現が難しいユーザー エクスペリエンスを提供できることです。ユーザーがウェブアプリの任意のページに初めてアクセスすると、個々のビューにアクセスするまで待つことなく、ウェブアプリのビューの表示に必要なすべての URL を事前にキャッシュに保存できます。
アプリをインストールするユーザーは、過去に表示したビューだけでなく、すべての部分がすぐに表示されることを期待しています。プリキャッシュを使用すると ウェブアプリでも同じことができます
事前キャッシュに保存する必要があるアセットはどれですか？
読み込まれるコンテンツの特定に関するガイドを再度参照し、どの URL の事前キャッシュ保存が最も適しているかをご確認ください。原則として、早い段階で読み込まれる HTML、JavaScript、CSS は事前にキャッシュに保存され、特定のページの基本構造を表示するために非常に重要です。
後で読み込まれるメディアやその他のアセットを事前キャッシュすることは避けることをおすすめします（ウェブアプリの機能にとって不可欠な場合を除く）。代わりに、ランタイム キャッシュ戦略を使用して、これらのアセットが継続的にキャッシュされるようにします。
常に、プレキャッシュには（アプリストアからアプリをインストールする場合と同様に）ユーザーのデバイスのネットワーク帯域幅とストレージを使用する必要があることに留意してください。事前キャッシュは慎重に行い、プレキャッシュ マニフェストの肥大化を避けるかどうかはデベロッパーの判断に委ねられています。
Workbox のビルドツールには、プレキャッシュ マニフェスト内のアイテム数と、プレキャッシュ ペイロードの合計サイズが表示されます。
ウェブアプリに繰り返しアクセスすると、ネットワークを回避できる機能により、時間の経過とともに節約された帯域幅がすぐに消費されるため、プレキャッシュの初期費用により長期的にメリットがあります。