ワークボックスを使用した事前キャッシュ

Service Worker の機能の一つは、必要なときにファイルをキャッシュに保存できることです。 表示されます。これを「プレキャッシュ」と呼びます。 事前キャッシュを使用すると、ブラウザにアクセスせずにキャッシュ内のファイルを提供できる トラフィックをルーティングしますサイトが必要とする重要なアセットに対してもプレキャッシュを使用する オフライン時: メインページ、スタイル、代替画像、重要なスクリプト。

Workbox を使うべき理由は何ですか。

事前キャッシュに Workbox を使用するかどうかは任意です。独自のコードを記述して Service Worker のインストール時に重要なアセットを事前キャッシュに保存する。 Workbox を使用する主な利点は、すぐに使用できるバージョン管理です。 Workbox を使用すると、キャッシュに保存されているアセットの更新の手間が このようなファイルのバージョニングと更新をお客様自身で管理する必要がある場合です。

マニフェストを事前キャッシュする

事前キャッシュは、URL と関連するバージョニング情報のリストに基づいて行われます。 できます。総称して プリキャッシュ マニフェスト。 マニフェストは「信頼できる情報源」想定していたすべての状態に対して 特定のバージョンのウェブアプリのプリキャッシュです。プリキャッシュ マニフェストは、 Workbox で使用されている形式 次のようになります。

[{
  url: 'app.abcd1234.js'
}, {
  url: 'offline.svg',
  revision: '7836745f'
}, {
  url: 'index.html',
  revision: '518747aa'
}]

Service Worker がインストールされると、3 つのキャッシュ エントリが キャッシュ ストレージ。1 つ目のアセットにはバージョニングが設定されています URL にすでに含まれている情報(app は実際のファイル名、 .abcd1234 には、ファイル拡張子の直前のバージョニング情報が含まれます。 .js)。Workbox のビルドツールでこれを検出し、リビジョン フィールドを除外できます。「 他の 2 つのアセットの URL にはバージョニング情報が含まれていないため、Workbox の ビルドツールは、ローカル モジュールのハッシュを含む個別の revision フィールドを作成します。 表示されます。

事前キャッシュ済みリソースの提供

キャッシュへのアセットの追加は、プレキャッシュのストーリーの一部にすぎません。 送信リクエストに応答する必要があります。そのためには Service Worker で fetch イベント リスナーを使用して、どの URL に し、キャッシュされたレスポンスを確実に返します。その際、 接続されていますService Worker はキャッシュからレスポンスを確認するため、 (ネットワークより前に使用)がありますが、 キャッシュ ファースト戦略

効率的な更新

プリキャッシュ マニフェストで、予期されるキャッシュを正確に表す state;マニフェスト内の URL とリビジョンの組み合わせが変更された場合、Service Worker は 以前のキャッシュに保存されたエントリが有効ではなくなったことを認識し、 更新しました。ネットワーク リクエストが 1 つあれば、ネットワーク モジュールによって自動的に Service Worker の一部としてブラウザを update check、 を使用して、更新が必要な事前キャッシュ済み URL を特定します。

事前キャッシュ済みリソースの更新

ウェブアプリの新しいバージョンをリリースするにつれ、 以前にプレキャッシュした URL を最新の状態にする、新しいアセットをプレキャッシュする、古いアセットを削除する あります。毎回完全なプリキャッシュ マニフェストを生成し続ける限り サイトを再構築する際に、そのマニフェストが「信頼できる情報源」として機能します。を キャッシュ状態を維持できます。

新しいリビジョン フィールドを含む既存の URL がある場合、または新しいリビジョン フィールドを含む URL がある場合 これは、Service Worker で、マニフェストに 更新処理の実行が必要になります。 install および activate 使用します。たとえばサイトに変更を加えた場合 最新のプリキャッシュ マニフェストで次の問題が発生した可能性があります。 変更点:

[{
  url: 'app.ffaa4455.js'
}, {
  url: 'offline.svg',
  revision: '7836745f'
}, {
  url: 'index.html',
  revision: '518747aa'
}]

それぞれの変更により、新しいリクエストを新しい HTTP リクエストに対して 以前にキャッシュに保存されたエントリ('offline.svg''index.html')を更新するために行われた処理 新しい URL('app.ffaa4455.js')を削除したり、削除して URL をクリーンアップしたりできます。 使用されなくなりました('app.abcd1234.js')。

真の「アプリストア」インストール エクスペリエンス

プレキャッシュのもう一つのメリットは、 「アプリストア」外で達成するのは困難 インストールできます。ユーザーがウェブアプリのページに 初めてアクセスすると サイトのいずれかを表示するために必要な URL をすべて事前キャッシュしておく ウェブアプリのビューに 1 つずつアクセスし、 できます。

ユーザーはアプリをインストールする際に、すべての要素がすばやく表示されることを期待します。 過去に視聴したビューだけではありませんプリキャッシュでも同じことが ウェブアプリとモバイルアプリのエクスペリエンスを 提供します

事前キャッシュに保存する必要があるアセットはどれですか。

「Google Workspace における Google Cloud の 最適な URL を把握できるようにすることです。一般的には、 早期に読み込まれる HTML、JavaScript、CSS を事前キャッシュし、 特定のページの基本構造を表示します。

後で読み込まれるメディアやその他のアセットは事前キャッシュしないことをおすすめします。 (ウェブアプリの機能に不可欠な場合を除きます)。代わりに、ランタイム キャッシュ戦略を使用して キャッシュ保存できます。

プレキャッシュではネットワーク帯域幅とストレージを使用することに注意してください。 (アプリストアからアプリをインストールするのと同様)です。 事前にキャッシュを慎重に行い、処理が肥大化しないように マニフェスト ファイルに記載されます。

Workbox のビルドツールにより、プリキャッシュ内のアイテム数が表示される プリキャッシュ ペイロードの合計サイズを指定します。

ウェブアプリのリピーターは、長期的に見れば、アプリの というのも、ネットワークを回避できる機能が備わっているため、 保存された帯域幅で経時的に変化します。