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

緩存設(shè)置得當(dāng)不但可減少用戶等待時(shí)間，提升體驗(yàn)，還節(jié)省服務(wù)器開銷省流量帶寬。

緩存的配置有兩種策略：

• 穩(wěn)定的內(nèi)容 + 長期緩存
• 經(jīng)常變動的內(nèi)容 + 使用前詢問

穩(wěn)定的內(nèi)容 + 長期緩存

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

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

可以看到，這種模式下，我們更新的是文件名，即資源的 URI 地址，而不是直接更新文件內(nèi)容。因?yàn)槲募痪彺婧?#xff0c;如果文件名沒變，瀏覽器是不會重新去獲取的。

經(jīng)常變動的內(nèi)容 + 使用前詢問

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

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

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

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

使用 ETag 的場景示例：

整個(gè)過程沒有對資源進(jìn)行重復(fù)下載。

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

相比方式一，這種方式始終會和服務(wù)器進(jìn)行一次溝通。

max-age 的注意事項(xiàng)

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

?比如設(shè)置緩存為如下格式時(shí)，

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

假設(shè)一個(gè)場景，頁面 A 包含一個(gè)公共腳本 common.js 和頁面 A 的業(yè)務(wù)腳本 a.js。當(dāng)頁面 A 首頁加載時(shí)，所有資源都正確緩存。

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

在請求頁面 B 之前，因?yàn)橐呀?jīng)緩存過 common.js，所以會使用緩存，但這期間文件有可能已經(jīng)更新。此時(shí)瀏覽器使用舊的 common.js 運(yùn)行頁面 B 勢必會出問題。

所以，對于經(jīng)常變動的內(nèi)容設(shè)置 max-age 是不推薦的做法。

多數(shù)情況下針對上面的問題，一次強(qiáng)刷就解決了，這也是有 bug 時(shí)研發(fā)會給出的高頻回復(fù)。

參考內(nèi)容

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