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 つのキャッシュ エントリが作成され、リストされた 3 つの URL のそれぞれに対して作成されます。最初のアセットのバージョニング情報はすでに URL に含まれています（app は実際のファイル名で、.abcd1234 にはファイル拡張子の直前のバージョニング情報が含まれます.js）。他の 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 のビルドツールは、プリキャッシュ マニフェスト内のアイテム数とプリキャッシュ ペイロードの合計サイズを確認するのに役立ちます。
ウェブアプリに繰り返しアクセスするユーザーにとっては、長期的には事前キャッシュの事前コストがかかります。なぜなら、ネットワークを回避できる機能によって、時間の経過とともに節約された帯域幅が即座にカバーされるからです。