網絡中數據傳輸是很耗時的，數據要在漫長的路徑中奔波，客戶端在數據完整到達前只能等待。如果能夠復用已經請求過的資源，勢必會讓整個頁面加載高效許多。這可以通過合理地設置服務器的緩存，與瀏覽器的緩存機制配合以達到最優。

緩存設置得當不但可減少用戶等待時間，提升體驗，還節省服務器開銷省流量帶寬。

緩存的配置有兩種策略：

• 穩定的內容 + 長期緩存
• 經常變動的內容 + 使用前詢問

穩定的內容 + 長期緩存

在知道文件內容不太可能變化的情況下，可對該資源進行長期緩存。

這種模式下瀏覽器獲取資源流程如下：

可以看到，這種模式下，我們更新的是文件名，即資源的 URI 地址，而不是直接更新文件內容。因為文件被緩存后，如果文件名沒變，瀏覽器是不會重新去獲取的。

經常變動的內容 + 使用前詢問

對于經常變動的資源，但地址又不能變，比如靜態博客頁面，則不能像上面那樣緩存。這種情況下可設置緩存為 no-cache。

需要注意的是，緩存 Header 的值不能按照字面意思來解釋，需要去理解它，比如：

• no-cache 并不是表示不要緩存，而是緩存該資源，但使用前先詢問服務器該資源是否有更新，而 no-store 才表示完全不緩存。
• must-revalidate 不是必需重新驗證資源有效性的意思，而是暗含了一個前提，就是資源如果還沒有超過設置的緩存時限 max-age 才重新驗證。

此模式下，服務器可通過下發 ETag 或 Last-Modified 響應頭，瀏覽器下次再請求時會查檢查已緩存的資源，并帶上相應的 If-None-Match 或 If-Modified-Since 請求頭，然后服務器再決定是否返回新的資源或告知瀏覽器直接使用本地緩存。

使用 ETag 的場景示例：

整個過程沒有對資源進行重復下載。

ETag/Last-Modified 不可用的情況下，服務器始終下發完整資源。

相比方式一，這種方式始終會和服務器進行一次溝通。

max-age 的注意事項

對易變的內容設置 max-age 方式的緩存容易引起各資源不一致的問題。

?比如設置緩存為如下格式時，

對于緩存時間小于 10 分鐘的資源，瀏覽器不會重新請求而是直接使用緩存。

假設一個場景，頁面 A 包含一個公共腳本 common.js 和頁面 A 的業務腳本 a.js。當頁面 A 首頁加載時，所有資源都正確緩存。

過了一段時間，切換到頁面 B，頁面 B 也包含公共腳本 common.js，同時有自己的業務腳本 b.js。

在請求頁面 B 之前，因為已經緩存過 common.js，所以會使用緩存，但這期間文件有可能已經更新。此時瀏覽器使用舊的 common.js 運行頁面 B 勢必會出問題。

所以，對于經常變動的內容設置 max-age 是不推薦的做法。

多數情況下針對上面的問題，一次強刷就解決了，這也是有 bug 時研發會給出的高頻回復。

參考內容

• Caching best practices & max-age gotchas
• HTTP Caching