workbox-cacheable-response

実行時にアセットをキャッシュに保存する場合、特定のレスポンスが「有効」で、保存と再利用が可能かどうかに関する万能なルールはありません。

workbox-cacheable-response モジュールは、数値のステータス コード、特定の値を持つヘッダーの有無、またはこの 2 つの組み合わせに基づいて、レスポンスをキャッシュに保存するかどうかを判断する標準的な方法を提供します。

ステータス コードに基づくキャッシュ

戦略の plugins パラメータに CacheableResponsePlugin インスタンスを追加することで、一連のステータス コードをキャッシュの対象と見なすようにワークボックス戦略を構成できます。

import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';

registerRoute(
  ({url}) =>
    url.origin === 'https://third-party.example.com' &&
    url.pathname.startsWith('/images/'),
  new CacheFirst({
    cacheName: 'image-cache',
    plugins: [
      new CacheableResponsePlugin({
        statuses: [0, 200],
      }),
    ],
  })
);

この構成は、https://third-party.example.com/images/ に対するリクエストのレスポンスを処理するときに、ステータス コードが 0 または 200 のリクエストをキャッシュに保存するよう Workbox に指示します。

ヘッダーに基づくキャッシュ

プラグインの作成時に headers オブジェクトを設定することで、キャッシュに追加する条件として特定のヘッダー値の存在を確認するようにワークボックス戦略を構成できます。

import {registerRoute} from 'workbox-routing';
import {StaleWhileRevalidate} from 'workbox-strategies';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';

registerRoute(
  ({url}) => url.pathname.startsWith('/path/to/api/'),
  new StaleWhileRevalidate({
    cacheName: 'api-cache',
    plugins: [
      new CacheableResponsePlugin({
        headers: {
          'X-Is-Cacheable': 'true',
        },
      }),
    ],
  })
);

/path/to/api/ を含むリクエスト URL のレスポンスを処理するときは、X-Is-Cacheable という名前のヘッダーを確認します（これはサーバーによってレスポンスに追加されます）。そのヘッダーが存在し、その値が true に設定されている場合は、レスポンスをキャッシュに保存できます。

複数のヘッダーが指定されている場合、関連付けられた値と一致するヘッダーは 1 つだけです。

ヘッダーとステータス コードに基づくキャッシュ

ステータスとヘッダー構成を混在させることができます。レスポンスがキャッシュに保存可能と見なされるには、両方の条件を満たす必要があります。つまり、レスポンスに構成されたステータス コードのいずれかが含まれ、かつ指定されたヘッダーが少なくとも 1 つ含まれている必要があります。

import {registerRoute} from 'workbox-routing';
import {StaleWhileRevalidate} from 'workbox-strategies';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';

registerRoute(
  ({url}) => url.pathname.startsWith('/path/to/api/'),
  new StaleWhileRevalidate({
    cacheName: 'api-cache',
    plugins: [
      new CacheableResponsePlugin({
        statuses: [200, 404],
        headers: {
          'X-Is-Cacheable': 'true',
        },
      }),
    ],
  })
);

デフォルトとは

cacheableResponse.CacheableResponsePlugin を明示的に構成せずに Workbox の組み込み戦略のいずれかを使用する場合、次のデフォルト条件を使用して、ネットワークから受信したレスポンスをキャッシュに保存するかどうかが決定されます。

• staleWhileRevalidate と networkFirst: ステータスが 0 のレスポンス（つまり、不透明なレスポンス）または 200 のレスポンスは、キャッシュに保存可能とみなされます。
• cacheFirst: ステータスが 200 のレスポンスはキャッシュ可能とみなされます。

デフォルトでは、レスポンス ヘッダーはキャッシュ保存可否の判断に使用されません。

デフォルトが異なるのはなぜですか？

デフォルトは、ステータスが 0 のレスポンス（つまり、不透明なレスポンス）がキャッシュに保存されるかどうかによって異なります。不透明なレスポンスの「ブラック ボックス」という性質のため、Service Worker は、レスポンスが有効かどうか、クロスオリジン サーバーから返されたエラー レスポンスを反映しているかどうかを知ることはできません。

staleWhileRevalidate や networkFirst など、キャッシュに保存されたレスポンスを更新する手段を含む戦略では、キャッシュが次回更新されたときに適切な正常なレスポンスが使用されるため、一時的なエラー レスポンスがキャッシュに保存されるリスクが軽減されます。

最初に受信したレスポンスをキャッシュに保存し、そのキャッシュに保存したレスポンスを無期限に再利用する戦略では、一時的なエラーがキャッシュに保存されて再利用された場合の影響はより深刻です。デフォルトでは、ステータス コードが 200 でない限り、cacheFirst はレスポンスの保存を拒否します。

高度な使用方法

Workbox 戦略の外部で同じキャッシュ ロジックを使用する場合は、CacheableResponse クラスを直接使用できます。

import {CacheableResponse} from 'workbox-cacheable-response';

const cacheable = new CacheableResponse({
  statuses: [0, 200],
  headers: {
    'X-Is-Cacheable': 'true',
  },
});

const response = await fetch('/path/to/api');

if (cacheable.isResponseCacheable(response)) {
  const cache = await caches.open('api-cache');
  cache.put(response.url, response);
} else {
  // Do something when the response can't be cached.
}