https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=zh-cn

我們唯一要做的就是確保服務器提供必要的 ETag 令牌。檢查您的服務器文檔中有無必要的配置標誌。
有沒有etag是服務器配置,

• 每個資源都可通過 Cache-Control HTTP 標頭定義其緩存策略
• Cache-Control 指令控制誰在什麽條件下可以緩存響應以及可以緩存多

HTTP 規範允許服務器返回 Cache-Control 指令，這些指令控制瀏覽器和其他中間緩存如何緩存各個響應以及緩存多久。
註：Cache-Control 標頭是在 HTTP/1.1 規範中定義的，取代了之前用來定義響應緩存策略的標頭（例如 Expires）。所有現代瀏覽器都支持 Cache-Control，因此，使用它就夠了。

“no-cache”和“no-store”

“no-cache”表示必須先與服務器確認返回的響應是否發生了變化，然後才能使用該響應來滿足後續對同一網址的請求。因此，如果存在合適的驗證令牌 (ETag)，no-cache 會發起往返通信來驗證緩存的響應，但如果資源未發生變化，則可避免下載。

相比之下，“no-store”則要簡單得多。它直接禁止瀏覽器以及所有中間緩存存儲任何版本的返回響應，例如，包含個人隱私數據或銀行業務數據的響應。每次用戶請求該資產時，都會向服務器發送請求，並下載完整的響應。

“public”與“private”

如果響應被標記為“public”，則即使它有關聯的 HTTP 身份驗證，甚至響應狀態代碼通常無法緩存，也可以緩存響應。大多數情況下，“public”不是必需的，因為明確的緩存信息（例如“max-age”）已表示響應是可以緩存的。

相比之下，瀏覽器可以緩存“private”響應。不過，這些響應通常只為單個用戶緩存，因此不允許任何中間緩存對其進行緩存。例如，用戶的瀏覽器可以緩存包含用戶私人信息的 HTML 網頁，但 CDN 卻不能緩存。

“max-age”

etag cache control