このドキュメントでは、以前のプレキャッシュについて説明しましたが、正しく行う方法については十分ではありません。これが重要なのは、Workbox を使用するかどうかにかかわらず、事前キャッシュが過剰に発生することになり、データと帯域幅を無駄にする可能性があるためです。ペイロードのプレキャッシュがユーザー エクスペリエンスに与える影響に注意する必要があります。
このドキュメントは一般的なガイドラインです。アプリケーションのアーキテクチャや要件によっては、ここで提案したものとは異なるやり方が必要になる場合がありますが、以下のガイドラインがデフォルトとして役立ちます。
すべきこと: 重要な静的アセットを事前キャッシュする
プレキャッシュの最適な候補は、重要な静的アセットですが、「クリティカル」アセットとみなすものは何でしょうか。デベロッパーの観点からは、アプリケーション全体を「クリティカル」と考えたくなるかもしれませんが、最も重要なのはユーザーの視点です。重要なアセットとは、ユーザー エクスペリエンスを提供するために不可欠なアセットを指します。
- グローバル スタイルシート。
- グローバル機能を提供する JavaScript ファイル。
- アプリケーション シェルの HTML（アーキテクチャに該当する場合）。
注意: これは一般的なガイドラインであり、厳格な推奨事項ではありません。アセットをプレキャッシュする場合は、プレキャッシュを多めにするのではなく、少なめにしておくことをおすすめします。
すべきこと: 複数ページにわたるウェブサイトのオフライン フォールバックを事前キャッシュする
一般的な複数ページのウェブサイトでは、ナビゲーション リクエストの処理にネットワーク ファーストまたはネットワークのみのキャッシュ戦略を使用していることがあります。
このような場合、ユーザーがオフライン中にナビゲーション リクエストを行ったときは、Service Worker が事前にキャッシュして、オフライン フォールバック ページで応答するように設定する必要があります。Workbox でこれを行う方法の 1 つとして、ナビゲーションのプリロードも利用したネットワークのみの戦略とオフライン フォールバックを併用できます。
import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute, Route} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
import * as navigationPreload from 'workbox-navigation-preload';
navigationPreload.enable();
// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);
// The network-only callback should match navigation requests, and
// the handler for the route should use the network-only strategy, but
// fall back to a precached offline page in case the user is offline.
const networkOnlyNavigationRoute = new Route(({request}) => {
return request.mode === 'navigate';
}, new NetworkOnly({
plugins: [
new PrecacheFallbackPlugin({
fallbackURL: '/offline.html'
})
]
}));
registerRoute(networkOnlyNavigationRoute);
これにより、ユーザーがオフラインになってキャッシュにないページに移動しても、少なくともオフライン コンテンツを入手できます。
検討する: 投機的プレキャッシュを検討
これは大きな可能性はありますが、特定のシナリオでのみ使用されるアセットを事前キャッシュすることに潜在的なメリットがあるのです。次のように考えてください。ユーザーは最初に追加のデータ ダウンロードが発生しますが、その一方でこうしたアセットに対する将来のリクエストを高速化できるという投機的な利点があります。
ただし、これを行う場合は細心の注意を払ってください。そうするとデータが浪費されやすいため、事実に基づき判断する必要があります。また、頻繁に変更されるアセットを投機的にプレキャッシュすることは避けてください。プレキャッシュ コードが新しいリビジョンを検出するたびに、追加のデータ使用量が発生します。アナリティクスでユーザーフローを観察して、ユーザーがどのような方向に向かっているかを確認しましょう。投機的にアセットをプリフェッチすることに疑問がある場合は、そうしないほうがよいでしょう。
推奨しない方法: 静的 HTML をプリキャッシュ
このガイドラインは、個別の HTML ファイルが動的に生成されるかアプリケーションのバックエンドによって提供されるのではなく、静的サイト生成ツールによって生成されるか、手動で作成される静的サイトに適用されます。ご使用のアーキテクチャに当てはまる場合は、ウェブサイトのすべての HTML ファイルを事前キャッシュしないことをおすすめします。
サイト全体の HTML ファイルをプレキャッシュする場合の問題の一つは、現時点で事前キャッシュされたマークアップが、Service Worker が更新されるまで、常にキャッシュから提供されることです。これはパフォーマンスの向上に役立ちますが、ウェブサイトの HTML が頻繁に変更されると、大幅なキャッシュ変更につながる可能性があります。
ただし、このルールにはいくつかの例外があります。少数の静的 HTML ファイルを含む小規模なウェブサイトをデプロイする場合は、それらのページをすべて事前キャッシュして、オフラインで利用できるようにしても問題ありません。特に大規模なウェブサイトでは、価値の高いいくつかのページを推測的に事前キャッシュし、オフラインでの代替手段として、他のページをキャッシュ保存するためにランタイム キャッシュを利用することを検討しましょう。
非推奨: レスポンシブな画像やファビコンを事前にキャッシュに保存する
これは一般的なガイドラインというよりルールです。レスポンシブ画像は、複雑な問題に対応する複雑なソリューションです。多くのユーザーが利用するデバイスが多く、デバイスごとに画面サイズやピクセル密度が異なり、他のフォーマットもサポートされています。レスポンシブ画像セット全体を事前キャッシュすると、ユーザーが最終的に 1 つの画像しかダウンロードすることになったときに、複数の画像を事前キャッシュしておくことになります。
ファビコンも同じような状況で、ウェブサイトでは多くの場合、さまざまな状況に合わせてファビコン一式が展開されています。ほとんどの場合、リクエストされるファビコンは 1 つのみであるため、ファビコン セット全体の事前キャッシュも同様に無駄になります。
ユーザーを優先し、レスポンシブな画像とファビコンのセットを事前にキャッシュに保存しない。代わりにランタイム キャッシュを使用してください。画像を事前キャッシュする必要がある場合は、レスポンシブ画像やファビコンのセットに含まれない、広く使用されている画像を事前キャッシュに保存します。SVG はデータ使用のリスクが少なく、単一の SVG が特定の画面のピクセル密度に関係なく適切にレンダリングされます。
非推奨: ポリフィルの事前キャッシュ
API に対するさまざまなブラウザ サポートはウェブ デベロッパーにとって永続的な課題であり、ポリフィルはその課題を解決する方法の一つです。ポリフィルのパフォーマンス コストを最小限に抑える一つの方法は、機能チェックを行い、それを必要とするブラウザに対してのみポリフィルを読み込むことです。
ポリフィルの条件付き読み込みは、現在の環境に対する実行時に発生するため、ポリフィルの事前キャッシュはギャンブルです。この方法のメリットを得られるユーザーもいれば、不要なポリフィルのために帯域幅を浪費するユーザーもいるでしょう。
ポリフィルを事前キャッシュしないでください。ランタイム キャッシュを利用して、データが無駄にならないよう、キャッシュを必要とするブラウザでのみキャッシュされるようにします。
まとめ
プレキャッシュには、ユーザーが実際に必要としているアセットを前もって事前に把握する必要がありますが、将来的なパフォーマンスと信頼性を優先するようにして確実に正しく処理できます。
特定のアセットを事前キャッシュすべきかどうかわからない場合は、そうしたアセットを除外し、それらを処理するためのランタイム キャッシュ ルートを作成するよう Workbox に指示することをおすすめします。いずれにしても、プレキャッシュについてはこのドキュメントの後半で詳しく説明しているため、今後、これらの原則をプレキャッシュのロジックに適用できます。