Service Worker 和兩個緩存

Question

我一直假設（雖然沒有看到它明確說明）以下是安裝服務工作者時 HTTPS 請求的路徑：

1. 瀏覽器遇到帶有 URL 的圖像。 啟動 HTTPS 請求。
2. 請求通過“內部”緩存，如果有資源，它將返回資源，除非在開發工具中選中“禁用緩存”。
3. 請求作為 fetch 事件發送給服務工作者。 在那里，您的自定義代碼可以查詢您的自定義緩存並查看資源是否已存儲在那里，並將其返回。 如果沒有，您可以將請求轉發到網絡。 （不確定“禁用緩存”是否在這里有任何影響）。

只是希望有人可以確認這是它的工作原理。

Answer 1

如果使用“內部緩存”是指瀏覽器緩存，則在訪問 Service Worker 緩存后訪問它（您需要將第 2 點與第 3 點交換）。
如果你設置了disable cache ，這將只影響瀏覽器緩存，而不影響 Service Worker。 到達這一點的請求，意味着在 Service Worker 緩存中找不到匹配項，將 go 直接發送到服務器端。

在使用 Service Worker 實現緩存策略時，您可以將瀏覽器緩存視為備用緩存。

您可以在下面找到執行 HTTP 請求時遵循的緩存順序。
您還可以閱讀web.dev 文章，詳細解釋這一點。

Answer 2

@Francesco 鏈接到一篇關於服務人員和 HTTP 請求的文章（參見他的回答中的圖表）。 但事實證明，這張圖是不完整的。 Google Chrome 的渲染引擎 Blink 也有一個緩存，在將請求傳遞給 service worker 之前會先檢查它。 devtools 設置“禁用緩存”禁用 Blink 的緩存。 在這里解釋：

Blink 內存緩存存儲什么？

所以實際上有三個緩存，它們是按這個順序傳遞的：1. Blink 的緩存，2. service worker 的緩存（如果實現的話），3. Browser 緩存。 再加上 CDN 中的緩存內容。