Service Worker キャッシュと HTTP キャッシュ

Service Worker のキャッシュ レイヤと HTTP キャッシュ レイヤで、一貫して同じまたは異なる有効期限ロジックを使用する場合の長所と短所。

Jonathan Chen

Service Worker と PWA が最新のウェブ アプリケーションの標準になりつつある一方で、リソースのキャッシュ保存 かつてないほど複雑化していますこの記事では、ブラウザ キャッシュ、 例:

• Service Worker のキャッシュと HTTP のキャッシュのユースケースと違い
• さまざまな Service Worker のキャッシュ有効期限戦略の長所と短所 HTTP キャッシュ戦略。

キャッシュ フローの概要

大まかに言うと、ブラウザはリソースをリクエストする際、以下のキャッシュ順序に従います。

1. Service Worker キャッシュ: リソースがキャッシュ内にあるかどうかを Service Worker がチェックし、 リソース自体を返すかどうかは、プログラムされたキャッシュ方式に基づいて決まります。備考 この処理は自動的に行われません。フェッチ イベント ハンドラを Service Worker でネットワーク リクエストをインターセプトし、リクエストが Service から提供されるように ワーカーのキャッシュに保存されます
2. HTTP キャッシュ（ブラウザ キャッシュ）: リソースが HTTP キャッシュに残し、まだ期限切れになっていない場合、ブラウザは自動的に HTTP キャッシュからリソースを取得します。
3. サーバーサイド: Service Worker のキャッシュにも HTTP のキャッシュにも何も見つからない場合、 ブラウザがネットワークにアクセスしてリソースをリクエストします。リソースが CDN のキャッシュに保存されていない場合、 配信元サーバーに返す必要があります。

キャッシュ レイヤ

Service Worker のキャッシュ

Service Worker は、ネットワークタイプの HTTP リクエストをインターセプトし、 キャッシュ戦略 ブラウザに返すリソースを決定します。Service Worker のキャッシュと HTTP キャッシュの汎用的目的は同じですが、Service Worker のキャッシュの方が たとえば、キャッシュの対象やキャッシュの実行方法をきめ細かく制御する方法があります。

Service Worker のキャッシュの制御

Service Worker が HTTP リクエストをevent リスナー（通常は fetch イベント）でトリガーされます。この コード スニペットは、 キャッシュ ファースト キャッシュ戦略について説明します。

Workbox を使用することを強くおすすめします。これにより、 一から再開発することです。たとえば 1 行の正規表現コードでリソース URL パスを登録する。

import {registerRoute} from 'workbox-routing';

registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);

Service Worker のキャッシュ保存戦略とユースケース

次の表に、Service Worker の一般的なキャッシュ戦略と、各キャッシュ戦略が役立つ状況を示します。

Service Worker のキャッシュのその他のメリット

Service Worker のキャッシュは、キャッシュ ロジックのきめ細かい制御に加え、次の機能も提供します。

• 送信元のメモリとストレージ容量の増加: ブラウザが HTTP キャッシュを割り当てます。 オリジンごとにリソースを定義します。その他の つまり、複数のサブドメインがある場合は、すべて同じ HTTP キャッシュを共有します。「 配信元/ドメインのコンテンツが HTTP キャッシュに長期間残っていることを保証する。対象 ユーザーがブラウザの設定 UI から手動でクリーンアップしてキャッシュを削除する場合があります。 ページのハードリロードをトリガーしますService Worker のキャッシュを使用すると、 キャッシュされたコンテンツがキャッシュされたままになる可能性が高まります。詳しくは、永続 ストレージをご覧ください。
• 不安定なネットワークやオフライン エクスペリエンスでの柔軟性の向上: HTTP キャッシュを使用すると、 リソースをキャッシュに保存するかしないかの二者択一のみとします。Service Worker のキャッシュ保存を使用 小さな「トラブル」を軽減し「stale-while-revalidate」戦略により 完全なオフライン エクスペリエンス（「キャッシュのみ」戦略を使用）を提供するか、 ページの一部を Service Worker のキャッシュから取得し、 必要に応じて「Set catch handler」戦略を使用し、一部の部分を除外します。

HTTP キャッシュ

ブラウザは、初めてウェブページと関連リソースを読み込んだときに、 HTTP キャッシュ。HTTP キャッシュは通常、特に設定されていない限りブラウザによって自動的に有効になります。 無効にすることはできません。

HTTP キャッシュを使用すると、リソースをキャッシュに保存するタイミングとキャッシュ保存の方法をサーバーに依存 長いです。

HTTP レスポンス ヘッダーで HTTP キャッシュの有効期限を制御する

サーバーがブラウザ リクエストに応答してリソースをリクエストすると、サーバーは HTTP レスポンス ヘッダーを使用して リソースをキャッシュする期間をブラウザに指示します。レスポンス ヘッダー: ウェブサーバーを構成する サーバーをご覧ください。

HTTP キャッシュの戦略とユースケース

HTTP キャッシュは、Service Worker のキャッシュよりもはるかにシンプルです。HTTP キャッシュでは、 時間ベース（TTL）のリソース有効期限ロジック。詳しくは、 どのレスポンス ヘッダー値を使用すればよいですか。 HTTP キャッシュ戦略の詳細については、概要をご覧ください。

キャッシュの有効期限ロジックの設計

このセクションでは、Service Worker 全体で一貫した有効期限ロジックを使用するメリットとデメリットについて説明します。 それぞれについて、異なる有効期限ロジックのメリットとデメリットについて解説します。 レイヤです。

以下のグリッチは、Service Worker のキャッシュと HTTP のキャッシュが、 さまざまなシナリオがあります

すべてのキャッシュ レイヤに一貫した有効期限ロジック

長所と短所を説明するために、3 つのシナリオ（長期、中期、 短期的と長期的なものです

シナリオ: 長期キャッシュ保存（キャッシュ、ネットワークへのフォールバック）

• キャッシュに保存されたリソースが有効である（30 日以内）: Service Worker はキャッシュに保存された リソースに即座にアクセスすることはできません。
• キャッシュに保存されたリソースの有効期限が切れたとき（30 日以上）: Service Worker はネットワークにアクセスして 取得します。ブラウザの HTTP キャッシュにはリソースのコピーがないため、ブラウザは サーバーサイドに置きます。

デメリット: このようなシナリオでは、HTTP キャッシュを使用すると、ブラウザは常に Service Worker でキャッシュの有効期限が切れたときに、リクエストをサーバー側に渡します。

シナリオ: 中期キャッシュ（再検証中ステイル）

• キャッシュに保存されたリソースが有効（1 日以下）の場合: Service Worker はキャッシュに保存された ネットワークに送られてそのリソースを取得します。ブラウザには HTTP キャッシュにリソースが保存されるため、そのコピーが Service Worker に返されます。
• キャッシュに保存されたリソースの有効期限が切れた場合（1 日以上）: Service Worker はキャッシュに保存された ネットワークに送られてそのリソースを取得します。ブラウザに HTTP キャッシュ内のリソースのコピーを作成します。つまり、サーバーサイドでリソースを取得します。

短所: Service Worker で HTTP キャッシュをオーバーライドするには、追加のキャッシュ無効化が必要です。 最大限に活用できるようにして示します。

シナリオ: 短期キャッシュ（ネットワークがキャッシュにフォールバック）

• キャッシュに保存されたリソースが有効である場合（10 分以内）: Service Worker はネットワークにアクセスする リソースを取得します。ブラウザは HTTP キャッシュにリソースのコピーを保持するため、 Service Worker にデータを送ります
• キャッシュに保存されたリソースの有効期限が切れた場合（10 分超）: Service Worker はキャッシュに保存された ネットワークに送られてそのリソースを取得します。ブラウザに HTTP キャッシュ内のリソースのコピーを作成します。つまり、サーバーサイドでリソースを取得します。

デメリット: 中期的なキャッシュ保存のシナリオと同様に、Service Worker には追加の HTTP キャッシュをオーバーライドして最新のリソースを あります。

あらゆるシナリオでの Service Worker

いずれの場合も、ネットワークがインターネットに接続されている場合は、Service Worker のキャッシュがキャッシュ内のリソースを返すことができます。 不安定です。一方、HTTP キャッシュは、ネットワークが不安定な場合やダウンしている場合には信頼できません。

Service Worker のキャッシュ レイヤと HTTP レイヤでのさまざまなキャッシュ有効期限ロジック

長所と短所を説明するために、再び長期、中期、短期を見てみます。 説明します。

シナリオ: 長期キャッシュ保存（キャッシュ、ネットワークへのフォールバック）

• キャッシュに保存されたリソースが Service Worker のキャッシュで有効な場合（90 日以内）: ワーカーはキャッシュされたリソースを即座に返します。
• キャッシュに保存されたリソースが Service Worker のキャッシュで期限切れになった場合（90 日以上）: ワーカーはネットワークにアクセスして リソースを取得しますブラウザには、 HTTP キャッシュに保存されているため、サーバーサイドで転送されます。

長所と短所:

• メリット: Service Worker がキャッシュ内のリソースを返すため、ユーザーは即時のレスポンスを実感できる すぐに通知されます。
• メリット: Service Worker では、キャッシュを使用するタイミングと使用するタイミングをより細かく制御できます。 リソースの新しいバージョンをリクエストします。
• デメリット: 明確に定義された Service Worker のキャッシュ戦略が必要です。

シナリオ: 期間中のキャッシュ保存（再検証中に失効）

• キャッシュに保存されたリソースが Service Worker のキャッシュで有効な場合（30 日以内）: ワーカーはキャッシュされたリソースを即座に返します。
• キャッシュに保存されたリソースが Service Worker のキャッシュで期限切れになった場合（30 日以上）: ネットワークにルーティングされます。ブラウザにリソースのコピーが サーバーサイドにルーティングします

長所と短所:

• メリット: Service Worker がキャッシュ内のリソースを返すため、ユーザーは即時のレスポンスを実感できる すぐに通知されます。
• メリット: Service Worker は、特定の URL に対する次のリクエストで 「バックグラウンドで」行われる再検証のおかげで、ネットワークから新しいレスポンスを受け取れます。
• デメリット: 明確に定義された Service Worker のキャッシュ戦略が必要です。

シナリオ: 短期キャッシュ（ネットワークがキャッシュにフォールバック）

• キャッシュに保存されたリソースが Service Worker のキャッシュで有効な場合（1 日以下）: ネットワークにルーティングされます。ブラウザは HTTP リクエストからリソースを キャッシュに保存されている場合ですネットワークがダウンした場合、Service Worker はネットワークから Service Worker のキャッシュ
• キャッシュに保存されたリソースが Service Worker のキャッシュで期限切れになった場合（1 日以上）: ワーカーはネットワークにアクセスして リソースを取得しますブラウザは IP アドレスからリソースを HTTP キャッシュ内のキャッシュされたバージョンの有効期限が切れているため、ネットワークにログインできません。

長所と短所:

• メリット: ネットワークが不安定またはダウンしている場合、Service Worker はキャッシュに保存された 即座に拒否できます。
• デメリット: Service Worker で HTTP キャッシュと HTTP メッセージをオーバーライドするには、追加のキャッシュ無効化が必要 「ネットワーク ファースト」にするできます。

まとめ

キャッシュ保存のシナリオの組み合わせは複雑であるため、1 つのルールを設計することは不可能 すべてのケースを網羅していますただし、前のセクションで示した調査結果から、 キャッシュ戦略の設計時に検討すべき推奨事項を以下に示します。

• Service Worker のキャッシュ ロジックに HTTP キャッシュの有効期限との整合性は必要ない できます。可能であれば、Service Worker で有効期限を長くするロジックを使用して、Service Worker に付与してください きめ細かな管理が可能です。
• HTTP キャッシュは依然として重要な役割を担っていますが、ネットワークが保護されている場合には信頼性に欠けます。 不安定です。
• 各リソースのキャッシュ戦略を見直して、Service Worker のキャッシュが確実に HTTP キャッシュと競合することなく、その価値を提供します。

その他の情報

• ネットワークの信頼性
• HTTP キャッシュを使用して不要なネットワーク リクエストを防ぐ
• HTTP キャッシュ Codelab
• Service Worker が実際にパフォーマンスに及ぼす影響を測定する
• Cache-Control と 有効期限の比較