【譯】-【緩存】最佳實踐

本文譯自: 這裏

本文已同步到個人博客

引言

緩存利用得當的話，有很大益處，好比節省帶寬，下降服務器壓力等，可是不少網站沒可以很好地利用緩存，形成一些相互依賴的資源出現不一樣步的狀況。

關於緩存的處理方案主要能夠分爲如下兩種：

方案一：資源內容保持不變+超長的max-age

Cache-Control: max-age=31536000

• 這個url對應的資源永遠保持不變
• 瀏覽器/CDN能夠將該資源緩存好久
• 對於沒有超過max-age的緩存內容能夠直接使用，而沒必要再向服務器請求

以下圖所示：

在這種狀況下，一個url對應的資源應該是一直保持不變的，若是咱們想更新資源，只能經過更改url的方式來實現：

<script src="/script-f93bca2c.js"></script>
<link rel="stylesheet" href="/styles-a837cb1e.css">
<img src="/cats-0e9a2ef4.jpg" alt="…">

能夠看到，url中帶有一串碼，該碼是與資源內容相關的，能夠是版本號，修改日期，或者文件內容的hash值。

大部分服務器端的框架會有一些工具來讓這件事情變得簡單，

但是，這種方式並不適用於一些文章或者博客之類的網站，這些網站的url不能經過版本號來管理，並且內容也是常常須要改變的。

方案二：內容可變，每次都須要服務器再次校驗（revalidated）

Cache-Control: no-cache

• 這個url對應的資源是可變的
• 本地緩存只有在服務器驗證過是最新的以後才能夠使用

（譯者注：可參照304場景）

以下圖所示：

注意：no-cache並非指不緩存，而是指在使用緩存以前，必須首先向服務器端確認資源是否爲最新。
no-store指不容許緩存。一樣的must-revalidate並不是是指必須從新驗證，它的意思是，只有當本地的緩存已經超過最長緩存時間時，才須要從新驗證。

在這種場景下，能夠在響應頭中添加ETag或者Last-Modified。這樣，當客戶端在下次請求的時候，就會在請求頭中帶上這些信息，分別對應的是If-None-Match和If-Modified-Since。服務器端根據該標識判斷資源是否爲最新的，若是是，則返回304狀態碼。

這種設置老是會須要一次網絡請求的（來驗證本地的緩存資源是否爲最新），所以相比於第一種方式，增長了網絡請求。