どのブラウザでも、ウェブアプリのオリジンに使用できるストレージの容量に上限が設定されています。実行時にキャッシュするデータを自動的にクリーンアップするように Workbox を設定できます。これにより、ウェブサイトのキャッシュ効率や信頼性に影響を及ぼしかねない保存容量の制限が発生することを回避できます。
どのような構成オプションがサポートされていますか？
ルートとランタイムのキャッシュ戦略を設定するときに、キャッシュするアセットの種類に最も適した設定を使用して構成された workbox-expiration から ExpirationPlugin のインスタンスを追加できます。
たとえば、次の構成が実行時にイメージをキャッシュするために使用され、明示的な制限と、割り当てを超過した場合の自動クリーンアップの両方を使用できます。
import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';
import {ExpirationPlugin} from 'workbox-expiration';
registerRoute(
({request}) => request.destination === 'image',
// Use a cache-first strategy with the following config:
new CacheFirst({
// You need to provide a cache name when using expiration.
cacheName: 'images',
plugins: [
new ExpirationPlugin({
// Keep at most 50 entries.
maxEntries: 50,
// Don't keep any entries for more than 30 days.
maxAgeSeconds: 30 * 24 * 60 * 60,
// Automatically cleanup if quota is exceeded.
purgeOnQuotaError: true
})
]
})
);
ExpirationPlugin を使用する場合は、maxEntries、maxAgeSeconds、またはその両方を設定する必要があります。purgeOnQuotaError は省略可能です。
maxEntries
これにより、特定のキャッシュのエントリ（つまり、一意の URL）の数に上限が適用されます。
特定の戦略で処理できる URL が少数の場合を除いて、通常はこの値を設定することをおすすめします。
maxAgeSeconds
この秒数以上前にキャッシュに追加されたエントリは古いと見なされ、次回キャッシュにアクセスしたときに自動的にクリーンアップされます。
この方法では、ストレージ割り当ての管理において maxEntries ほど効果的ではありません。エントリがすべて短時間で追加されていれば、キャッシュが任意のサイズに大きくなる可能性があるためです。これは、必要な鮮度に上限があり、古いエントリを保持してもウェブアプリにとってほとんど価値がない場合に特に便利です。
purgeOnQuotaError
このオプションを使用すると、ウェブアプリが保存容量を超過した場合に、特定のキャッシュを自動的に削除しても問題ないというマークをつけることができます。
現在、このオプションのデフォルトは false です。通常、ランタイム キャッシュは削除しても復元力があります。そのため、このオプションは true に設定することをおすすめします。これにより、ウェブアプリがストレージの制約を受けて自動的に復元できるようになります。
保存が許可されるデータ量はどれくらいですか？
各ブラウザにはストレージの上限があるため、答えは一つではありません。また、一部のブラウザでは、デバイスの空き容量に応じて動的に上限が変動するため、実際の上限は予告なく変更される場合があります。
一部のブラウザでは、navigator.storage.estimate() を介して、オリジンが使用しているおおよその保存容量と上限を照会するためのインターフェースが公開されています。この容量を独自のウェブアプリで使用する方法について詳しくは、利用可能な保存容量の見積もりをご覧ください。
Chrome のシークレット モードに関する特別な考慮事項
Chrome のシークレット モードでウェブアプリを開くと、保存容量に特別な制限が課され、通常のブラウジング環境には当てはまりません。デバイスの空き容量にかかわらず、割り当て上限は約 100 MB です。
不透明なレスポンスに注意する
予想以上に割り当て使用量が予想外に多くなる一般的な原因は、不透明なレスポンスのランタイム キャッシュにあります。つまり、CORS を有効にせずに作成されたリクエストに対するクロスオリジン レスポンスです。
ブラウザでは、セキュリティ上の考慮事項として、こうした不透明なレスポンスの割り当ての影響が自動的に大きくなります。たとえば Chrome では、レスポンスが不透明で数キロバイトでも、約 7 メガバイトの割り当て使用量になります。
不透明なレスポンスのキャッシュを開始すると、すぐに想定よりもはるかに多くの割り当てを消費できるため、ベスト プラクティスは、maxEntries とともに ExpirationPlugin を使用し、場合によっては purgeOnQuotaError を適切に構成することです。