サービスワーカー応答キャッシュヘッダー

Question

私はサービスワーカーが応答のキャッシュヘッダーに関してどのように動作するかを理解しようとしています。私はサービスワーカーのカップルを今実装しましたが、ヘッダーのキャッシュ、アイテムのキャッシュ期間などを心配する必要はありませんでした。今、エンタープライズプロダクションサイトで実装しています。

基本的にサービスワーカーを使用している場合、httpキャッシュは完全にバイパスされていますか？

次に、私たちのために行ったHTTPキャッシュのようなリソースの有効期限/無効化を処理するためのフレームワークを構築する必要がありますか？または私はゴミを言っていますか？

誰かがこれを明確にすることができれば非常に役に立ちます。私がそれを見る方法には、3つの潜在的なシナリオがあります。

A）。ネットワークリクエスト=>サービスワーカーフェッチ=>（ブラウザキャッシュ？）< =>サーバー

B）。ネットワークリクエスト< =>（ブラウザキャッシュ？）< =>サービスワーカーフェッチ< =>サーバー

C）。ネットワークリクエスト=>サービスワーカーフェッチ< =>サーバー

これはローカルでテストしましたが、C）と思われます。正しい実装であるため、開発者はキャッシュヘッダー/期間の抽象化を犠牲にして制御できます。

私はこの問題を解消し、サービスワーカーのキャッシュヘッダーを読み、尊重するためのフレームワークを構築する前に明確にしたいと思います。

Answer 1

A）が正しいモデルです。サービスワーカーがページを制御する場合、すべてのネットワーク要求は、ブラウザキャッシュまたはネットワークを調べる前に、サービスワーカーのfetchイベントハンドラをトリガーします。

サービスワーカーがfetch()で明示的に、またはcache.add()/cache.addAll()で暗黙的にネットワーク要求を行うたびに、ブラウザの「従来の」キャッシュが最初に応答のために参照されます。サーバーへのネットワーク要求は、ブラウザーのキャッシュに有効な応答がない場合にのみ行われます。

これはあなたの好みに応じて動作することがあります。その動作が予期しない場合は微妙なバグにさらされることがあります。

https://jakearchibald.com/2016/caching-best-practices/の詳細な説明はthings to avoidとways to take advantage of this behaviorです。

Answer 2

どのようにリクエストを設定するかによって異なります。 Fetch APIを使用すると、リクエストがブラウザのHTTPキャッシュとどのように対話するかを制御できます。

たとえば、リクエストのキャッシュモードをno-storeに設定して、HTTPキャッシュをバイパスすることができます。それとも、それが古くなっている場合でも、キャッシュされた応答を返しますforce-cacheので、ブラウザにリクエストのキャッシュモードを設定することができます：デフォルトの要求のキャッシュモードによって

fetch("some.json", {cache: "force-cache"}) 
    .then(function(response) { /* consume the response */ }); 

がdefaultです。この場合、リクエストは通常​​どおり動作します。明らかに、サービスワーカーがハードコードされた応答を返すのではなく、実際に要求を実行した場合のみです。

詳細については、Fetch Standard,​​およびUsing Service Workers MDN pageを確認してください。