どのブラウザでも、ウェブアプリのオリジンで使用できるストレージの容量に上限があります。ウェブサイトのキャッシュ効率と信頼性に影響する可能性のあるストレージ割り当ての上限に達しないように、ランタイムでキャッシュに保存されたデータを自動的にクリーンアップするように 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 メガバイトです。
不透明なレスポンスに注意してください。
割り当て使用量が想定よりも高くなる一般的な原因は、不透明なレスポンス（CORS を有効にせずに行われたリクエストに対するクロスオリジン レスポンス）のランタイム キャッシュです。
ブラウザは、セキュリティ上の考慮事項として、これらの不透明なレスポンスの割り当ての影響を自動的に増やします。たとえば Chrome では、数キロバイトの不透明なレスポンスでも、最終的には割り当て使用量に 約 7 メガバイトが加算されます。
不透明なレスポンスをキャッシュに保存すると、想定よりもはるかに多くの割り当てがすぐに使用される可能性があるため、maxEntries と ExpirationPlugin を適切に構成し、必要に応じて purgeOnQuotaError を使用することをおすすめします。