前端性能優(yōu)化(二)-瀏覽器緩存機(jī)制

覽器緩存對于前端一點(diǎn)都不陌生，最常見的就是，新版本上線了，測試卻說這怎么還沒有變化呢？使用 ctr + F5 強(qiáng)制刷新之后，立馬就好了。或者清除瀏覽器緩存，按住ctr+shift+delete，彈出如圖：

我們會發(fā)現(xiàn)目前瀏覽器緩存的圖片和文件的大小。或者進(jìn)入chrome://chrome-urls/找到chrome://cache/ 就可以看到所有緩存的地址列表。對于瀏覽器緩存，前端對它是又愛又恨，有時(shí)想保留，有時(shí)想禁掉，所以看看瀏覽器緩存到底是怎樣的？

一、什么是瀏覽器緩存？

瀏覽器緩存就是瀏覽器根據(jù) url 第一次訪問網(wǎng)站之后，將網(wǎng)站的 html、css、js、圖片等文件復(fù)制一份保留到瀏覽器中，當(dāng)你二次訪問這個(gè) url 的網(wǎng)站時(shí)，如果網(wǎng)站沒有明確表示有更新時(shí)，瀏覽器直接在緩存中查找內(nèi)容，不會再次請求網(wǎng)頁內(nèi)容，只有網(wǎng)頁明確表示有更新時(shí)，瀏覽器才會向服務(wù)器發(fā)起網(wǎng)路請求，再次下載網(wǎng)頁。

如上圖，百度首頁就是使用了緩存機(jī)制，首次訪問之后 web資源被緩存，在后面重復(fù)請求中，資源直接在緩存中讀取，而不是向服務(wù)器請求資源。

二、為什么使用緩存？

2.1、為什么很多網(wǎng)站二次打開速度很快？

網(wǎng)頁二次打開很快，主要原因是第一次加載頁面過程中，緩存了部分耗時(shí)數(shù)據(jù)，這一現(xiàn)象，對于單頁面應(yīng)用開發(fā)非常明顯。

上一篇文章《瀏覽器工作原理》中，瀏覽器工作流程介紹，輸入網(wǎng)址回車以后瀏覽器向服務(wù)器發(fā)起服務(wù)之前，會現(xiàn)在瀏覽器緩存中查詢是否有需要的文件？如果有則直接在緩存中獲取文件，避免向服務(wù)器請求和下載文件，所以節(jié)省了一部分時(shí)間。

2.2、瀏覽器緩存優(yōu)點(diǎn)

1、減少網(wǎng)絡(luò)帶寬消耗

對于網(wǎng)站運(yùn)營者或者訪問網(wǎng)頁的用戶，帶寬就代表著 money ，過多的消耗帶寬，我們服務(wù)器配置就得升級，使用瀏覽器緩存之后，就會減少網(wǎng)絡(luò)流量，降低運(yùn)營成本。

2、降低服務(wù)器壓力

使用瀏覽器緩存之后，除第一次訪問需要向服務(wù)器請求網(wǎng)站全部資源，后續(xù)訪問可以重復(fù)使用瀏覽器本地緩存，減少對服務(wù)器的請求，間接降低服務(wù)器的壓力，同時(shí)，搜索引擎的爬蟲也會根據(jù)緩存過期機(jī)制降低抓取的頻率，也可以降低服務(wù)器壓力。

3、減少網(wǎng)絡(luò)延遲，加快網(wǎng)頁加載

瀏覽器緩存 web資源后，減少網(wǎng)絡(luò)請求，可以更快速地獲取到服務(wù)器返回?cái)?shù)據(jù)，同時(shí)使用瀏覽器緩存內(nèi)的文件比服務(wù)器獲取快很多，所以網(wǎng)頁加載速度明顯快很多。

三、瀏覽器的緩存規(guī)則

對于瀏覽器端的緩存來講，這些規(guī)則是在 http 協(xié)議和 meta 標(biāo)簽中定義的。分別從兩個(gè)維度：新鮮度和校驗(yàn)值，規(guī)定瀏覽器是否可以直接使用緩存中的副本，還是直接從服務(wù)器獲取最新資源。

3.1、新鮮度(過期)：瀏覽器緩存的有效期，緩存必須滿足以下兩個(gè)條件，瀏覽器才會認(rèn)為是最新的，可以直接使用。

含有完整的過期時(shí)間控制頭信息，并在有效期內(nèi)。
瀏覽器已經(jīng)使用過這個(gè)副本，并且在會話中已經(jīng)檢查過新鮮度。

3.2、校驗(yàn)值(驗(yàn)證)：服務(wù)器返回資源的時(shí)候，會在響應(yīng)頭信息中帶上資源實(shí)體標(biāo)簽 Entity Tag，可以用來作為瀏覽器再次請求過程的校驗(yàn)標(biāo)識，如果發(fā)現(xiàn)校驗(yàn)標(biāo)識不匹配，說明資源已經(jīng)被修改過或過期，瀏覽器需要重新請求資源。

四、如何控制緩存？

緩存規(guī)則可以設(shè)置在html的meta標(biāo)簽，也可以設(shè)置在http協(xié)議頭內(nèi)。

4.1、前端 html 中 meta 標(biāo)簽

在 html 頁面中加入緩存設(shè)置，代碼如下：

<meta http-equiv="Pragma" content="no-cache"  />
<!-- Pragma是http1.0版本中給客戶端設(shè)定緩存方式之一 -->

上邊代碼，禁止瀏覽器緩存，瀏覽器每次訪問網(wǎng)頁都要去服務(wù)器請求。事實(shí)這種禁用緩存形式作用有限：

只有IE瀏覽器才能標(biāo)識這段 meta 的含義，其他主流瀏覽器僅認(rèn)識 “Cache-Control:no-store” 的 meta 標(biāo)簽。
在IE瀏覽器中，并不一定添加 pragma，但是會讓當(dāng)前網(wǎng)頁每次都會向服務(wù)器發(fā)送請求。

4.2、HTTP協(xié)議頭

http請求和響應(yīng)頭中，與緩存相關(guān)的常見類型：

規(guī)則	消息報(bào)頭	值/示例	類型	作用
新鮮度	Pragma	no-cache	響應(yīng)	告訴瀏覽器忽略資源的緩存副本，每次訪問都需要去服務(wù)器拉取【http1.0中存在的字段，在http1.1已被拋棄，使用Cache-Control替代，但為了做http協(xié)議的向下兼容，很多網(wǎng)站依舊會帶上這個(gè)字段】
	Expires	Mon, 15 Aug 2016 03:56:47 GMT	響應(yīng)	啟用緩存和定義緩存時(shí)間。告訴瀏覽器資源緩存過期時(shí)間，如果還沒過該時(shí)間點(diǎn)則不發(fā)請求【http1.0中存在的字段，該字段所定義的緩存時(shí)間是相對服務(wù)器上的時(shí)間而言的，如果客戶端上的時(shí)間跟服務(wù)器上的時(shí)間不一致（特別是用戶修改了自己電腦的系統(tǒng)時(shí)間），那緩存時(shí)間可能就沒啥意義了。在HTTP 1.1版開始，使用Cache-Control: max-age=秒替代】
	Cache-Control	no-cache	響應(yīng)	告訴瀏覽器忽略資源的緩存副本，強(qiáng)制每次請求直接發(fā)送給服務(wù)器，拉取資源，但不是“不緩存”
		no-store	響應(yīng)	強(qiáng)制緩存在任何情況下都不要保留任何副本
		max-age=[秒]	響應(yīng)	指明緩存副本的有效時(shí)長，從請求時(shí)間開始到過期時(shí)間之間的秒數(shù)
		public	響應(yīng)	任何路徑的緩存者（本地緩存、代理服務(wù)器），可以無條件的緩存該資源
		private	響應(yīng)	只針對單個(gè)用戶或者實(shí)體（不同用戶、窗口）緩存資源
	Last-Modified	Mon, 15 Aug 2016 03:56:47 GMT	響應(yīng)	告訴瀏覽器這個(gè)資源最后的修改時(shí)間。服務(wù)器將資源傳遞給客戶端時(shí)，會將資源最后更改的時(shí)間以“Last-Modified: GMT”的形式加在實(shí)體首部上一起返回給客戶端【只能精確到秒級，如果某些文件在1秒鐘以內(nèi)，被修改多次的話，它將不能準(zhǔn)確標(biāo)注文件的修改時(shí)間】
	If-Modified-Since	Mon, 15 Aug 2016 03:56:47 GMT	請求	其值為上次響應(yīng)頭的Last-Modified值，再次向web服務(wù)器請求時(shí)帶上頭If-Modified-Since。web服務(wù)器收到請求后發(fā)現(xiàn)有頭If-Modified-Since則與被請求資源的最后修改時(shí)間進(jìn)行比對。若最后修改時(shí)間較新，說明資源又被改動過，則響應(yīng)整片資源內(nèi)容（寫在響應(yīng)消息包體內(nèi)），包括更新Last-Modified的值，HTTP 200；若最后修改時(shí)間較舊，說明資源無新修改，則響應(yīng)HTTP 304(無需請求，節(jié)省瀏覽)，告知瀏覽器繼續(xù)使用所保存的cache
校驗(yàn)值	ETag	"fd56273325a2114818df4f29a628226d"	響應(yīng)	告訴瀏覽器當(dāng)前資源在服務(wù)器的唯一標(biāo)識符（生成規(guī)則由服務(wù)器決定）
	If-None-Match	"fd56273325a2114818df4f29a628226d"	請求	當(dāng)資源過期時(shí)（使用Cache-Control標(biāo)識的max-age），發(fā)現(xiàn)資源具有Etage聲明，則再次向web服務(wù)器請求時(shí)帶上頭If-None-Match（Etag的值）。web服務(wù)器收到請求后發(fā)現(xiàn)有頭If-None-Match則與被請求資源的相應(yīng)校驗(yàn)串進(jìn)行比對，決定返回200或304

各種類型之間的關(guān)系和區(qū)別：

Cache-Control 與 Expires：它兩作用一樣，都表明當(dāng)前資源的有效期，控制瀏覽器是取緩存還是直接向服務(wù)器獲取，Cache-Control可以設(shè)置的更細(xì)致，如果同時(shí)設(shè)置，它的優(yōu)先級高于Expires。
Last-Modified / ETag 與 Cache-Control / Expires：配置Last-Modified/ETag的情況下，瀏覽器再次訪問URL的資源，還是會發(fā)送請求到服務(wù)器，詢問文件是否已經(jīng)修改，如果沒有，服務(wù)器會給瀏覽器返回304，瀏覽器直接從本地緩存中取就好了，反之，服務(wù)器會直接向?yàn)g覽器返回?cái)?shù)據(jù)。Cache-Control / Expires 檢測本地緩存是否還在有效期內(nèi)，在有效期內(nèi)，直接使用本地緩存，阻止發(fā)送請求。如果同時(shí)設(shè)置，Cache-Control / Expiress 優(yōu)先級更高。一般情況下，兩者配合使用，因?yàn)榧词狗?wù)器設(shè)置緩存時(shí)間, 當(dāng)用戶點(diǎn)擊“刷新”按鈕時(shí)，瀏覽器會忽略緩存繼續(xù)向服務(wù)器發(fā)送請求，這時(shí)Last-Modified/ETag將能夠很好利用304，從而減少響應(yīng)開銷。
Last-Modified 與 ETag：ETag主要是為了解決Last-Modified比較難解決的問題：1、Last-Modified標(biāo)注的最后修改只能精確到秒級，如果某些文件在1秒鐘以內(nèi)，被修改多次的話，它將不能準(zhǔn)確標(biāo)注文件的新鮮度。2、如果某些文件會被定期生成，當(dāng)有時(shí)內(nèi)容并沒有任何變化，但Last-Modified卻改變了，導(dǎo)致文件沒法使用緩存。3、有可能存在服務(wù)器沒有準(zhǔn)確獲取文件修改時(shí)間，或者與代理服務(wù)器時(shí)間不一致等情形。ETag是服務(wù)器自動生成或開發(fā)者生成對應(yīng)資源在服務(wù)器的唯一標(biāo)識符，能夠更加精準(zhǔn)控制緩存。兩者可以一起使用，服務(wù)器優(yōu)先驗(yàn)證ETag，一致時(shí)，才會繼續(xù)比對Last-Mofifed，才決定是否要返回304。

五、不能緩存的請求

并不是所有的請求都能被緩存，無法被緩存的有：

post 請求無法被緩存。
需要根據(jù)cookie、認(rèn)證信息等決定輸入內(nèi)容的動態(tài)請求不能被緩存。
http響應(yīng)頭中不包含Last-Modified/ETag，也不包含Cache-Control/Expiress的請求無法被緩存。
http信息頭明確設(shè)置Cache-Control:no-cache,pragma:no-cache或Cache-Control:max-age=0瀏覽器不緩存時(shí)。

存是個(gè)老生長談的問題，對于前端工程師來講更是我們的必修課。或許很多人會說我的項(xiàng)目并沒有問題，根本不需要聊什么緩存。如果真的是這樣，只能證明你前端道路才剛剛開始。

背景

小郭今天分享緩存的原因在于：公司的一個(gè)核心APP中嵌入了SPA，而且應(yīng)用核心都分布在SPA中，功能復(fù)雜且重。問題出現(xiàn)了：應(yīng)用核心頁面打開一直處于加載狀態(tài)，排除掉弱網(wǎng)環(huán)境的原因，重點(diǎn)就在于沒有緩存，每次進(jìn)入頁面都需要重載DOM和數(shù)據(jù)，拖慢頁面打開速度。

那應(yīng)該處理緩存問題呢？接下來小郭從三個(gè)方向來講解。

瀏覽器緩存策略

在了解瀏覽器緩存前，我們需要先了解一下相關(guān)的概念：cache-control，expires，last-Modified，ETag。

瀏覽器通過請求頭實(shí)現(xiàn)緩存，關(guān)鍵的請求頭有cache-control，expires，last-Modified，ETag等。我們從時(shí)間和空間兩個(gè)角度來看瀏覽器緩存。

時(shí)間

瀏覽器發(fā)送第一次請求：不緩存，服務(wù)端根據(jù)設(shè)定的緩存策略返回相應(yīng)的header，如：cache-control，expires，last-Modified，ETag。

瀏覽器發(fā)送第二次請求：

強(qiáng)緩存策略：不需要和服務(wù)端通信就決定是否使用緩存，cache-control優(yōu)先級大于expires① 有cache-control且不過期，返回本地磁盤緩存，狀態(tài)值200；② 有expires且不過期，返回本地磁盤緩存，狀態(tài)值200。
協(xié)商緩存策略：需要和服務(wù)端通信決定是否用緩存，Etag優(yōu)先級大于last-Modified。① 有Etag，請求頭添加If-None-Match，值就是上次返回的Etag值，然后發(fā)送給服務(wù)端。服務(wù)端對比If-None-Match與現(xiàn)有的Etag值是否一樣；一樣的話只返回header，狀態(tài)碼304，瀏覽器從本地磁盤獲取緩存信息；不一樣走正常流程，返回header+body，狀態(tài)碼200；② 有l(wèi)ast-Modified，添加請求頭If-Modified-Since，值是上次返回的last-Modified，然后發(fā)送給服務(wù)端。服務(wù)端對比If-Modified-Since與現(xiàn)有的是否一樣；一樣的話返回只返回header，狀態(tài)碼304，瀏覽器從本地磁盤獲取緩存信息；不一樣走正常流程，返回header+body，狀態(tài)碼200
無緩存

空間

瀏覽器和服務(wù)端：服務(wù)端需要決定使用哪種緩存策略并在響應(yīng)頭返回；前端不需要設(shè)置，是瀏覽器本身機(jī)制。
html和靜態(tài)資源：通常html不設(shè)置緩存，因?yàn)槠渌Y源的入口都是html文件；靜態(tài)資源（js，css，圖片等）會設(shè)置緩存

部署時(shí)緩存的問題

如果緩存就按理論上設(shè)置，那就太簡單了。在實(shí)際應(yīng)用有個(gè)嚴(yán)重的問題，我們不僅要緩存代碼，還需要更新代碼。如果靜態(tài)資源名字不變，怎么讓瀏覽器即能緩存又能在有新代碼時(shí)更新。最簡單的解決方式就是靜態(tài)資源路徑添加一個(gè)版本值，版本不變就走緩存策略，版本變了就加載新資源。如下：

<script src="xx/xx.js?v=24334452"></script>

然而這種處理方式在部署時(shí)有問題。

解決方法：靜態(tài)資源和頁面是分開部署

先部署頁面再部署靜態(tài)資源，會出現(xiàn)用戶訪問到舊的資源
先部署靜態(tài)資源再部署頁面，會出現(xiàn)沒有緩存用戶加載到新資源而報(bào)錯(cuò)

這些問題的本質(zhì)是以上的部署方式是“覆蓋式發(fā)布”，解決方式是“非覆蓋式發(fā)布”。即用靜態(tài)資源的文件摘要信息給文件命名，這樣每次更新資源不會覆蓋原來的資源，先將資源發(fā)布上去。這時(shí)候存在兩種資源，用戶用舊頁面訪問舊資源，然后再更新頁面，用戶變成新頁面訪問新資源，就能做到無縫切換。簡單來說就是給靜態(tài)文件名加hash值。

那如何實(shí)現(xiàn)呢？

現(xiàn)在前端代碼都用webpack之類的構(gòu)建工具打包，那么結(jié)合webpack該怎么做，怎么才能做到持久化緩存？

webpack持久化緩存

一、webpack給文件名添加hash值是很簡單的，但hash/chunkhash/contenthash要用哪個(gè)呢？

官方定義
hash: unique hash generated for every build
chunkhash: hashes based on each chunks' content
contenthash: hashes generated for extracted content

根據(jù)分析，contenthash才是我們需要的，內(nèi)容有更新，hash值才會更新。

二、webpack會打包業(yè)務(wù)代碼、第三方庫及運(yùn)行時(shí)代碼，為保證緩存互不干擾，應(yīng)該將它們提取出來。

第三方庫提取方式是設(shè)置optimization的splitChunks的cacheGroups。splitChunks能提取模塊，cacheGroups能緩存模塊，并且cacheGroups的配置會覆蓋splitChunks相同配置，既能提取又能緩存，故只需設(shè)置cacheGroups。

運(yùn)行時(shí)代碼的提取方式為配置runtimeChunk，默認(rèn)為false，表示運(yùn)行時(shí)代碼嵌入到不同的chunk文件中；現(xiàn)在將運(yùn)行時(shí)代碼提取出來，并命名為manifest。

module.exports = {
  entry: {
    index: "./src/index.js",
    bar: "./src/bar.js"
  },
  output: {
    filename: "[name].[contenthash].js"
  },
  optimization: {
    splitChunks: {
      cacheGroups: {
        vendor: {
          test:/[\\/]node_modules[\\/]/,
          name: "vendors",
          chunks: "all"
        }
      }
    },
    runtimeChunk: {
      name: "manifest"
    }
  }
};

三、 moduleName 和 chunkName 對文件的影響

module：就是js模塊
chunk：webpack編譯過程中由多個(gè)module組成的文件
bundle：bundle是chunk文件的最終狀態(tài)，是webpack編譯后的結(jié)果

一個(gè)文件被分離為3個(gè)文件，文件間怎么相互依賴的，會影響彼此打包，解決方法是將moduleId和chunkId改成按照文件路徑生成。

optimization: {
  moduleIds: 'hashed',
  namedModules: true,
  namedChunks: true
}

這樣子moduleId在編譯后的文件是文件目錄的hash值，更加安全。這也是namedChunks在production默認(rèn)為false的原因，不想依賴的文件路徑在編譯后的文件直接展示，但是為了持久性緩存，這里也只能打開。

四、CSS文件緩存

當(dāng)css代碼提取成單獨(dú)文件，當(dāng)我們改變css時(shí)，怎么保證不影響引用它的js文件呢？配置如下：

plugins: [
  new MiniCssExtractPlugin({
    filename: "[contenthash].css"
  })
]

webpack持久化緩存目標(biāo)是當(dāng)且僅當(dāng)該文件內(nèi)容變動才改變該文件名字的hash值

const MiniCssExtractPlugin = require("mini-css-extract-plugin");
module.exports = { 
  output: { 
    filename: [name].[contenthash].js, // 讓hash值只在內(nèi)容變動時(shí)更新 
    chunkFilename: [name].[contenthash].js // 動態(tài)引入的模塊命名，同上 
  }, 
  module: { 
    rules: [ { 
      test: /\.css$/, 
      use: [ 
        "loader: MiniCssExtractPlugin.loader", // 提取出來css "css-loader" 
      ] 
    } ] 
  }, 
  optimization: { 
    moduleIds: "hashed", // 混淆文件路徑名 
    runtimeChunk: { name: 'manifest' }, // 提取runtime代碼命名為manifest 
    namedModules: true, // 讓模塊id根據(jù)路徑設(shè)置，避免每增加新模塊，所有id都改變，造成緩存失效的情況 
    namedChunks: true, // 避免增加entrypoint，其他文件都緩存失效 
    cacheGroups: { 
      vendor: { // 提取第三方庫文件 
        test: /[\\/]node_modules[\\/]/, 
        name: 'vendors', chunks: 'all', 
      }, 
    },
  } 
  plugins: [ 
    new webpack.HashedModuleIdsPlugin(), // 與namedModules: true作用一樣 
    new MiniCssExtractPlugin({ 
      filename: "[contenthash].css", // css文件也是按contenthash命名 
      chunkFilename: "[contenthash].css", // 動態(tài)引入的css命名，同上 
    }) 
  ], 
}

總結(jié)

瀏覽器有其緩存機(jī)制，想要既能緩存又能在部署時(shí)沒有問題，需要給靜態(tài)文件名添加hash值。在webpack中，有些配置能讓我們實(shí)現(xiàn)持久化緩存。感興趣的同學(xué)可以自行去測試哦！

有任何問題可以在下方留言，想了解更多前端知識歡迎關(guān)注公眾號“一郭鮮”，文章也將同步于公眾號，前端學(xué)習(xí)不迷路

一、是什么
函數(shù)緩存，就是將函數(shù)運(yùn)算過的結(jié)果進(jìn)行緩存

本質(zhì)上就是用空間（緩存存儲）換時(shí)間（計(jì)算過程）

常用于緩存數(shù)據(jù)計(jì)算結(jié)果和緩存對象

二、如何實(shí)現(xiàn)
實(shí)現(xiàn)函數(shù)緩存主要依靠閉包、柯里化、高階函數(shù)，這里再簡單復(fù)習(xí)下

1-閉包  
	- 閉包可以理解成，函數(shù) + 函數(shù)體內(nèi)可訪問的變量總和
	- add函數(shù)本身，以及其內(nèi)部可訪問的變量，即 a = 1，這兩個(gè)組合在?起就形成了閉包
  
    (function() {
        var a = 1;
        function add() {
            const b = 2
            let sum = b + a
            console.log(sum); // 3
        }
        add()
      })()
2-柯里化    
	- 將一個(gè)二元函數(shù)拆分成兩個(gè)一元函數(shù)
	// 非函數(shù)柯里化
    var add = function (x,y) {
        return x+y;
    }
    add(3,4) //7

    // 函數(shù)柯里化
    var add2 = function (x) {
        //**返回函數(shù)**
        return function (y) {
            return x+y;
        }
    }
    add2(3)(4) //7

3-高階函數(shù)
  - 通過接收其他函數(shù)作為參數(shù)或返回其他函數(shù)的函數(shù)
    function foo(){
      var a = 2;

      function bar() {
        console.log(a);
      }
      return bar;
    }
    var baz = foo();
    baz();//2
	- 函數(shù) foo 如何返回另一個(gè)函數(shù) bar，baz 現(xiàn)在持有對 foo 中定義的bar 函數(shù)的引用。由于閉包特性，a的值能夠得到
  
三、應(yīng)用場景
    雖然使用緩存效率是非常高的，但并不是所有場景都適用，因此千萬不要極端的將所有函數(shù)都添加緩存

    以下幾種情況下，適合使用緩存：

    對于昂貴的函數(shù)調(diào)用，執(zhí)行復(fù)雜計(jì)算的函數(shù)
    對于具有有限且高度重復(fù)輸入范圍的函數(shù)
    對于具有重復(fù)輸入值的遞歸函數(shù)
    對于純函數(shù)，即每次使用特定輸入調(diào)用時(shí)返回相同輸出的函數(shù)