瀏覽器緩存的相關知識介紹

引言

開發者來講，瀏覽器充當了重要角色。瀏覽器緩存(Brower Caching)是瀏覽器在本地磁盤對用戶最近請求過的文檔進行存儲，當訪問者再次訪問同一頁面時，瀏覽器就能夠直接從本地磁盤加載文檔。瀏覽器緩存的優勢有： （1）、減小了冗餘的數據傳輸，節省了網費， （2）、減小了服務器的負擔，大大提高了網站的性能， （3）、加快了客戶端加載網頁的速度

瀏覽器緩存規則

強制緩存

不會向服務器發送請求，直接從緩存中讀取資源，在chrome控制檯的network選項中能夠看到該請求返回200的狀態碼，而且size顯示from disk cache或from memory cache。from memory cache表明使用內存中的緩存，from disk cache則表明使用的是硬盤中的緩存，瀏覽器讀取緩存的順序爲memory –> disk。

描述

協商緩存

協商緩存就是強制緩存失效後，瀏覽器攜帶緩存標識向服務器發起請求，由服務器根據緩存標識決定是否使用緩存的過程，主要有如下兩種狀況： •協商緩存生效，返回304和Not Modified 協商緩存生效 •協商緩存失效，返回200和請求結果 協商緩存失效

描述

舉例來講， C：S，你幾歲了？ S：C，我18歲了。 C：S，你幾歲了？我猜你18歲了。 S：你知道還問我？（304） C：S，你幾歲了？我猜你18歲了。 S：C，我19歲了。（200）

描述

Respouse Headers的設置與緩存的關係

Respouse Headers緩存相關請求頭與說明

描述

下面經過demo，進行了了驗證(因爲第一次請求都是須要從服務器端獲取數據，返回200，因此就再也不貼驗證圖了) last-Modified

第二次請求數據未更改時：

描述

第二次請求數據更改：

客戶端第二次請求此URL時，根據HTTP協議的規定，瀏覽器會向服務器傳送If-Modified-Since報頭(HttpRequest Header)，詢問該時間以後文件是否有被修改過：若是服務器端的資源沒有變化，則自動返回HTTP304（NotChanged.）狀態碼，內容爲空，這樣就節省了傳輸數據量。當服務器端代碼發生改變或者重啓服務器時，則從新發出資源，返回和第一次請求時相似。從而保證不向客戶端重複發出資源，也保證當服務器有變化時，客戶端可以獲得最新的資源。

二、ETag工做原理

第二次發送請求：

（1）數據沒有變化

描述

服務端經過對比etag與if-none-match，數據未發生變化時，etag不會發生變化，服務端檢測二者相等，返回304

(2) 數據發生變化

數據發生變化時，etag發生變化，服務端檢測二者不相等，返回304，返回200

三、 Expires

第二次請求（在有效時間內）：

描述

第二次請求（不在有效時間內）：

描述

當請求在有效時間類，客戶端會直接讀取瀏覽器緩存，返回200（from disk cache),當不在有效時間內時，會進行協商緩存，返回304. 四、 Cache-Control

（在HTTP/1.0中可能部分沒實現，僅僅實現了Pragma: no-cache）,HTTP/1.1中，Cache-Control是最重要的規則，主要用於控制網頁緩存。好比當Cache-Control:max-age=300時，則表明在這個請求正確返回時間（瀏覽器也會記錄下來）的5分鐘內再次加載資源，就會命中強緩存。常見有如下六個屬性值：

描述

咱們主要對經常使用的相關屬性進行了驗證，包括max-age，no-cache,no-store

（1） max-age

當max-age=0時，表示瀏覽器不會進行緩存，以下圖所示：

第二次請求：

描述

當max-age = 60，表示瀏覽器緩存60s

第二次請求（60秒之內）：

描述

第二次請求（60秒之外）：

描述

由此可看出，在60s之內，瀏覽器會直接從緩存中獲取數據，超過60s，瀏覽器會從新從服務器端獲取數據。

各請求頭之間的關係

Cache-Control的no-cache與Etag或Last-Modified

no-cache控制客戶端緩存內容，是否使用緩存則須要通過協商緩存來驗證決定。咱們具體以實例來理解：

if (req.headers["if-modified-since"] === data) {
        res.writeHead(304, "keep cache", {
            "Content-Type": "text/plain",
            "Cache-Control": "no-cache",
            "last-modified": data,
            //"Expires": datae
        })
        res.end();
} else {
    res.writeHead(200, "OK", {
        "Content-Type": "text/plain",
        "Cache-Control": "no-cache",
        "last-modified": data,
        // "Expires": datae
    })
}
複製代碼

第二次請求數據無變化:

描述

第二次請求數據發生變化：

描述

描述

當Cache-Control設爲no-cache時，須要使用協商緩存判斷是否使用緩存，當第二次訪問時，將Last-Modified與 if-modified-since進行比較，若相同，則使用協商緩存，返回304，若不一樣，則從新訪問服務端，返回200。no-cache與Etag和Last-Modified是同樣的原理，這裏就再也不實驗。

Cache-Control的no-store與Etag或Last-Modified

no-store即全部內容都不會被緩存，即不使用強制緩存，也不使用協商緩存。

if (req.headers["if-modified-since"] === data) {
            res.writeHead(304, "keep cache", {
                "Content-Type": "text/plain",
                "Cache-Control": "no-store",
                "last-modified": data,
                //"Expires": datae
                "Etag": number
            })
            res.end();
        } else {
            res.writeHead(200, "OK", {
                "Content-Type": "text/plain",
                "Cache-Control": "no-store",
                "last-modified": data,
               // "Expires": datae
                "Etag": number
        })
複製代碼

第二次請求：

描述

描述

說明，當catch-control設爲no-store時，瀏覽器不會在本地緩存數據，客戶端每次訪問都會向服務器請求數據。

關於 Cache-Control: max-age=秒 和 Expires

Expires = 時間，HTTP 1.0 版本，緩存的載止時間，容許客戶端在這個時間以前不去檢查（發請求） max-age = 秒，HTTP 1.1版本，資源在本地緩存多少秒。 若是max-age和Expires同時存在，則被Cache-Control的max-age覆蓋。

Expires 的一個缺點就是，返回的到期時間是服務器端的時間，這樣存在一個問題，若是客戶端的時間與服務器的時間相差很大，那麼偏差就很大，因此在HTTP 1.1版開始，使用Cache-Control: max-age=秒替代。

res.writeHead(200, "keep cache", {
    "Content-Type": "text/plain",
    "Cache-Control": "max-age=60",
    //"last-modified": data,
    "Expires": datae
    // "Etag": number
})
複製代碼

第二次請求（60s以後）：

描述

描述

能夠看出，雖然Expires的期限未至，但max-age=60s，60s後，瀏覽器便會從新訪問服務器，很明顯，若是max-age和Expires同時存在，則被Cache-Control的max-age覆蓋。

關於 Cache-Control: max-age=秒 和Etag或Last-Modified

猜測：當max-age過時後，是否會判斷etag或Last-Modified，進行協商緩存了？
複製代碼

咱們以事實來講話：

if (req.headers["if-modified-since"] === data) {
            res.writeHead(304, "keep cache", {
                "Content-Type": "text/plain",
                "Cache-Control": "max-age=60",
                "last-modified": data,
                //"Expires": datae
               // "Etag": number
            })
            res.end();
        } else {
          res.writeHead(200, "OK", {
              "Content-Type": "text/plain",
              "Cache-Control": "max-age=60",
              "last-modified": data,
              //"Expires": datae
              // "Etag": number
        })
      }
複製代碼

第二次請求（60s之內）:

描述

第二次請求，數據未發生變化（60s之外）:

描述

第二次請求，當數據發生變化時(60s外)：

描述

描述

由此咱們能夠獲得，當max-age的時間過時後，瀏覽器會進入協商緩存，經過比較last-modify與if-modified-since，若相等，則返回304，從緩存中讀取數據，或不相等，返回200，從服務端讀取數據。Etag原理與last-modify同樣，這裏就再也不重複。

五、Cache-Control 與last-modify與Etag

講到這裏，可能咱們會有個疑問，感受etag與last-modify的原理同樣，做用同樣，爲何還會有兩個了。咱們就分析下這二者的區別： last-modify的缺點： 一些週期性修改的文件，修改時間變了但內容沒變，此時不但願從新GET； 一些文件修改很是頻繁，好比1秒內修改了屢次，Last-Modified只能精確到秒； 一些服務器不能獲得文件修改的精確時間； ETag是HTTP/1.1標準開始引入的，它是對Last-Modified的補充。 當etag與last-modify同時存在時，若是同時有 etag 和 last-modified 存在，在發送請求的時候會一次性的發送給服務器，沒有優先級，服務器會比較這兩個信息（在具體實現上，大多數作法針對這種狀況只會比對 etag）。 咱們仍是經過實例來看具體狀況：

if (req.headers["if-none-match"] == number) {
            if (req.headers["if-modified-since"] === data){
                res.writeHead(304, "keep cache", {
                    "Content-Type": "text/plain",
                   // "Cache-Control": "no-cache",
                   "Cache-Control": "max-age=60",
                    "last-modified": data,
                   // "Expires": datae,
                    "Etag": number
                })
                res.end();
            }
        } else {
            res.writeHead(200, "OK", {
                "Content-Type": "text/plain",
                "Cache-Control": "no-cache",
                "last-modified": data,
                //"Expires": datae
                "Etag": number
            })
        }
複製代碼

第二次訪問數據無變化：

描述

第二次訪問last-modify有變化：

描述

第二次訪問etag變化：

描述

描述

同時改變就不演示了，其實大多數狀況下，當咱們內容改變時，經過相關插件監控，last-modify和etag都會改變，這樣就會返回200，從服務器端讀取數據。

6 、Cache-Control 與last-modify與Etag與Expires

一般Cache-Control 與 Last-Modified, Etag, Expire 是一塊兒混合使用的，特別是 Last-Modified 和 Expire 常常一塊兒使用。Last-Modified,Etag,Expires 三個同時使用時。先判斷 Expire ，而後發送 Http 請求，服務器同時判斷 last-modified和 Etag ，必須都沒有過時，才能返回 304 響應。 Cache-Control —— 請求服務器以前 Expires —— 請求服務器以前 If-None-Match (Etag) —— 請求服務器 If-Modified-Since (Last-Modified) —— 請求服務器 咱們一樣經過實例來看：

（1）咱們將cache-control設爲no-cache，容許使用協商緩存，Expires設爲2020年，保證不會到期，而後看下狀況：

if (req.headers["if-none-match"] == number) {
        if (req.headers["if-modified-since"] === data){
            res.writeHead(304, "keep cache", {
                "Content-Type": "text/plain",
                // "Cache-Control": "no-cache",
                "Cache-Control": "max-age=60",
                "last-modified": data,
                "Expires": datae,
                "Etag": number
            })
            res.end();
        }
    } else {
        res.writeHead(200, "OK", {
            "Content-Type": "text/plain",
            // "Cache-Control": "no-cache",
            "Cache-Control": "max-age=60",
            "last-modified": data,
            "Expires": datae,
            "Etag": number
        })
    }
複製代碼

第二次請求，數據不發生變化：

描述

描述

其實這裏，若是隻有expires時，應該不會向服務端發起請求，會出現200（from disk cache）.當設置了cache-control爲no-cache，會覆蓋expires，表示須要進入協商緩存這一環節，若檢測到數據沒變化，則返回304.

(2) 咱們將cache-control設爲max-age=60，容許使用協商緩存，Expires設爲2020年，保證不會到期，

而後看下狀況：

第二次請求（60s之內）

描述

因爲還在max-age期限內，因此會直接讀取緩存，返回200（from disk cache）

第二次請求（60s之後），數據未變化:

描述

第二次請求（60s之後）當數據發生變化時：

描述

描述

60s之後，因爲max-age過時，瀏覽器會向服務器發送信息，若數據未變化，返回304，若變化返回200和數據，因爲請求了服務器，max-age會從新計時，又進入強制緩存。這裏能夠看出，expires與max-age功能同樣，爲何還有會兩個，其實expires是HTTP1.0中使用的，Expires要求客戶端和服務端的時鐘嚴格同步，HTTP1.1中引入Cache-Control來克服Expires頭的限制。

講到這裏，其實它們之間的關係已經很明瞭了,作個總結：

Cache-Control —— 請求服務器以前 Expires —— 請求服務器以前 If-None-Match (Etag) —— 請求服務器 If-Modified-Since (Last-Modified) —— 請求服務器 當cache-control的max-age與Expires時間未過時時，不會向服務器發送請求，使用強緩存。 當cache-control設置爲no-cache時，會使用協商緩存。 當cache-control設置爲no-store時，不使用緩存，每次都會向服務器發送請求。 Cache-control是克服expires缺陷，HTTP1.1引入，優先級高於expires。 ETag是HTTP/1.1標準開始引入的，它是對Last-Modified的補充。

瀏覽器緩存與前端性能優化

首先分別對無緩存，協商緩存，強緩存進行9次請求，得出各自耗費的時間。很明顯，強緩存所耗時間是最短的。無緩存即每次都須要發送http請求，服務端返回200和數據，協商緩存須要發送一次http請求，服務端進行判斷，數據未變返回304，客戶端讀取瀏覽器緩存，變化返回200和數據，而強緩存是不發送http請求，客戶端直接讀取瀏覽器緩存。因此瀏覽器緩存與前端性能就主要圍繞在是否發送http請求或發送http請求多少來進行優化了。 那麼減小http請求有哪些方式了？

合併圖片

CSSSprites直譯過來就是CSS精靈，可是這種翻譯顯然是不夠的，其實就是經過將多個圖片融合到一副圖裏面，而後經過CSS的一些技術佈局到網頁上。特別是圖片特別多的網站，若是能用css sprites下降圖片數量，帶來的將是速度的提高。

合併css/js

由於咱們在瀏覽器中打開一個頁面，頁面中所須要用到的每個css，js文件，     客戶端都須要發送一次http請求到服務器端獲取這些文件，因此在頁面的設計時將瀏覽器一次訪問須要的js，css合併成一個文件，這樣能夠減小http請求來提升網站性能。

充分利用強緩存

對於CSS，Javascript，Logo，圖標等這些靜態資源文件更新的頻率都比較低，因此將這些靜態資源文件使用強緩存，這樣就能夠減小http請求，從而提升性能。頁面的初次訪問者會進行不少HTTP請求，咱們經過設置Expires頭和Cache-Control的max-age，是這些組件可以緩存足夠長的時間，這樣第二次請求時就直接讀取瀏覽器緩存，從而避免發送http請求，加載速度就會提升不少。 可是經過使用一個長久的Expires頭，可使這些組件被緩存，下次訪問的時候，就能夠減小沒必要要的HTPP請求，從而提升加載速度。在某些時候，靜態資源文件變換須要更新到客戶端的瀏覽器緩存中，這種狀況下能夠經過改變文件的文件名來實現，即便用瀏覽器緩存的網站若是須要更新CSS，JS，Logo等信息，能夠經過改變文件名的方式進行更新。當咱們的文件跟新時，咱們最但願的是咱們更改了哪裏，對應的部分進行更新。這裏咱們就引入數據摘要要算法對文件求摘要信息，摘要信息與文件內容一一對應，就有了一種能夠精確到單個文件粒度的緩存控制依據。目前成熟的解決方案：

FIS的解決方案

如今已經跟新到fis3了，fis3中封裝工具方法，咱們調用fis3進行版本發佈，就會自動實現上述部署。 咱們只須要在fis-confid.js中配置

fis.match('*.{js,css,png}', {
   useHash: true
});
複製代碼

這樣文件會在打包後的發佈版本對應的文件添加惟一的hash值 能夠看出，js/css/png等都被加上了md5 hash值，這樣當咱們版本中其中一個文件變化，hash纔會變，從而保證瀏覽器能夠讀取更改的文件。Fis3跟webpack同樣是個複雜的打包工具，這只是其中一個小部分。

webpack的解決方案

webpack經過對不一樣文件進行hash/chunkhash/contenthash的設置 對png|jpe?g|gif等的設置：

{
            test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
        loader: 'url-loader',
        options: {
          limit: 10000,
          name: utils.assetsPath('img/[name].[hash:7].[ext]')
        }
      },
      {
        test: /\.(mp4|webm|ogg|mp3|wav|flac|aac)(\?.*)?$/,
        loader: 'url-loader',
        options: {
          limit: 10000,
          name: utils.assetsPath('media/[name].[hash:7].[ext]')
        }
      }
複製代碼

對js的設置：

output: {
    path: config.build.assetsRoot,
    filename: utils.assetsPath('js/[name].[chunkhash].js'),
    chunkFilename: utils.assetsPath('js/[id].[chunkhash].js')
  },
複製代碼

對css的設置：

filename: utils.assetsPath('css/[name].[contenthash].css'),
allChunks: true,
複製代碼

當咱們打包時，對應的文件會有惟一標誌符:

當有文件更改後，對應的hash值就會變化，瀏覽器就會向服務器從新請求該對應更改文件。

壓縮組件

從HTTP1.1開始，Web客戶端能夠經過HTTP請求中的Accept-Encoding頭來表示對壓縮的支持Accept-Encoding: gzip,deflate.若是Web服務器看到請求中有這個頭，就會使用客戶端列出來的方法中的一種來進行壓縮。Web服務器經過響應中的Content-Encoding來通知Web客戶端。

下面咱們來看看具體實例

Eg1:騰訊網 對於png等靜態資源的設置：

經過對max-age的設置，是瀏覽器緩存時間爲600s，600s以後便會使用協商緩存，這裏主要經過last-modify進行比較。

對於css的設置:

對於css，騰訊網首先進行了打包處理，而後只設置了60s的緩存，60s以後再次請求便會進入協商緩存。

對於js：

對於js，一樣進行了打包處理，而後設置了60s的緩存，60s以後再次請求便會進入協商緩存。

eg2網易首頁： 對於png等靜態資源:

網易首頁將png等靜態資源設置緩存時間爲262800s，至關於3天左右的時間。在這期間，再次請求都會使用強緩存。

對於css的設置:

對css的設置，緩存時間達到315360000s,至關於10年，誇張了點。

對於js:

對於js的設置，將max-age設置爲3600s,以後便會經過判斷etag和last-modify進行協商判斷，進入協商緩存。

不過，因爲一個網站有很是多的png，js,css，因此對於特別的狀況，須要特殊的設置。對於不多變化的靜態文件，能夠設置很長的緩存時間，例如10年。對於常變化的，就能夠不捨緩存時間或很短好比60s。合理設置瀏覽器緩存將會大大提高網頁加載速度，提高前端性能。

參考資料

瀏覽器緩存詳解：blog.csdn.net/ywh147/arti…

http: baike.baidu.com/item/http/2…

node中文官網：nodejs.org/zh-cn/