このページは Cloud Translation API によって翻訳されました。

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

Jeff Posnick

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

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