整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
覽器緩存對于前端一點都不陌生，最常見的就是，新版本上線了，測試卻說這怎么還沒有變化呢？使用 ctr + F5 強制刷新之后，立馬就好了。或者清除瀏覽器緩存，按住ctr+shift+delete，彈出如圖：
我們會發(fā)現(xiàn)目前瀏覽器緩存的圖片和文件的大小。或者進入chrome://chrome-urls/找到chrome://cache/ 就可以看到所有緩存的地址列表。對于瀏覽器緩存，前端對它是又愛又恨，有時想保留，有時想禁掉，所以看看瀏覽器緩存到底是怎樣的？
瀏覽器緩存就是瀏覽器根據(jù) url 第一次訪問網(wǎng)站之后，將網(wǎng)站的 html、css、js、圖片等文件復(fù)制一份保留到瀏覽器中，當你二次訪問這個 url 的網(wǎng)站時，如果網(wǎng)站沒有明確表示有更新時，瀏覽器直接在緩存中查找內(nèi)容，不會再次請求網(wǎng)頁內(nèi)容，只有網(wǎng)頁明確表示有更新時，瀏覽器才會向服務(wù)器發(fā)起網(wǎng)路請求，再次下載網(wǎng)頁。
如上圖，百度首頁就是使用了緩存機制，首次訪問之后 web資源被緩存，在后面重復(fù)請求中，資源直接在緩存中讀取，而不是向服務(wù)器請求資源。
2.1、為什么很多網(wǎng)站二次打開速度很快？
網(wǎng)頁二次打開很快，主要原因是第一次加載頁面過程中，緩存了部分耗時數(shù)據(jù)，這一現(xiàn)象，對于單頁面應(yīng)用開發(fā)非常明顯。
上一篇文章《瀏覽器工作原理》中，瀏覽器工作流程介紹，輸入網(wǎng)址回車以后瀏覽器向服務(wù)器發(fā)起服務(wù)之前，會現(xiàn)在瀏覽器緩存中查詢是否有需要的文件？如果有則直接在緩存中獲取文件，避免向服務(wù)器請求和下載文件，所以節(jié)省了一部分時間。
2.2、瀏覽器緩存優(yōu)點
1、減少網(wǎng)絡(luò)帶寬消耗
對于網(wǎng)站運營者或者訪問網(wǎng)頁的用戶，帶寬就代表著 money ，過多的消耗帶寬，我們服務(wù)器配置就得升級，使用瀏覽器緩存之后，就會減少網(wǎng)絡(luò)流量，降低運營成本。
2、降低服務(wù)器壓力
使用瀏覽器緩存之后，除第一次訪問需要向服務(wù)器請求網(wǎng)站全部資源，后續(xù)訪問可以重復(fù)使用瀏覽器本地緩存，減少對服務(wù)器的請求，間接降低服務(wù)器的壓力，同時，搜索引擎的爬蟲也會根據(jù)緩存過期機制降低抓取的頻率，也可以降低服務(wù)器壓力。
3、減少網(wǎng)絡(luò)延遲，加快網(wǎng)頁加載
瀏覽器緩存 web資源后，減少網(wǎng)絡(luò)請求，可以更快速地獲取到服務(wù)器返回數(shù)據(jù)，同時使用瀏覽器緩存內(nèi)的文件比服務(wù)器獲取快很多，所以網(wǎng)頁加載速度明顯快很多。
對于瀏覽器端的緩存來講，這些規(guī)則是在 http 協(xié)議和 meta 標簽中定義的。分別從兩個維度：新鮮度和校驗值，規(guī)定瀏覽器是否可以直接使用緩存中的副本，還是直接從服務(wù)器獲取最新資源。
3.1、新鮮度(過期)：瀏覽器緩存的有效期，緩存必須滿足以下兩個條件，瀏覽器才會認為是最新的，可以直接使用。
3.2、校驗值(驗證)：服務(wù)器返回資源的時候，會在響應(yīng)頭信息中帶上資源實體標簽 Entity Tag，可以用來作為瀏覽器再次請求過程的校驗標識，如果發(fā)現(xiàn)校驗標識不匹配，說明資源已經(jīng)被修改過或過期，瀏覽器需要重新請求資源。
緩存規(guī)則可以設(shè)置在html的meta標簽，也可以設(shè)置在http協(xié)議頭內(nèi)。
4.1、前端 html 中 meta 標簽
在 html 頁面中加入緩存設(shè)置，代碼如下：
<meta http-equiv="Pragma" content="no-cache" />
<!-- Pragma是http1.0版本中給客戶端設(shè)定緩存方式之一 -->上邊代碼，禁止瀏覽器緩存，瀏覽器每次訪問網(wǎng)頁都要去服務(wù)器請求。事實這種禁用緩存形式作用有限：
4.2、HTTP協(xié)議頭
http請求和響應(yīng)頭中，與緩存相關(guān)的常見類型：
規(guī)則 | 消息報頭 | 值/示例 | 類型 | 作用 |
新鮮度 | Pragma | no-cache | 響應(yīng) | 告訴瀏覽器忽略資源的緩存副本，每次訪問都需要去服務(wù)器拉取【http1.0中存在的字段，在http1.1已被拋棄，使用Cache-Control替代，但為了做http協(xié)議的向下兼容，很多網(wǎng)站依舊會帶上這個字段】 |
Expires | Mon, 15 Aug 2016 03:56:47 GMT | 響應(yīng) | 啟用緩存和定義緩存時間。告訴瀏覽器資源緩存過期時間，如果還沒過該時間點則不發(fā)請求【http1.0中存在的字段，該字段所定義的緩存時間是相對服務(wù)器上的時間而言的，如果客戶端上的時間跟服務(wù)器上的時間不一致（特別是用戶修改了自己電腦的系統(tǒng)時間），那緩存時間可能就沒啥意義了。在HTTP 1.1版開始，使用Cache-Control: max-age=秒替代】 | |
Cache-Control | no-cache | 響應(yīng) | 告訴瀏覽器忽略資源的緩存副本，強制每次請求直接發(fā)送給服務(wù)器，拉取資源，但不是“不緩存” | |
no-store | 響應(yīng) | 強制緩存在任何情況下都不要保留任何副本 | ||
max-age=[秒] | 響應(yīng) | 指明緩存副本的有效時長，從請求時間開始到過期時間之間的秒數(shù) | ||
public | 響應(yīng) | 任何路徑的緩存者（本地緩存、代理服務(wù)器），可以無條件的緩存該資源 | ||
private | 響應(yīng) | 只針對單個用戶或者實體（不同用戶、窗口）緩存資源 | ||
Last-Modified | Mon, 15 Aug 2016 03:56:47 GMT | 響應(yīng) | 告訴瀏覽器這個資源最后的修改時間。服務(wù)器將資源傳遞給客戶端時，會將資源最后更改的時間以“Last-Modified: GMT”的形式加在實體首部上一起返回給客戶端【只能精確到秒級，如果某些文件在1秒鐘以內(nèi)，被修改多次的話，它將不能準確標注文件的修改時間】 | |
If-Modified-Since | Mon, 15 Aug 2016 03:56:47 GMT | 請求 | 其值為上次響應(yīng)頭的Last-Modified值，再次向web服務(wù)器請求時帶上頭If-Modified-Since。web服務(wù)器收到請求后發(fā)現(xiàn)有頭If-Modified-Since則與被請求資源的最后修改時間進行比對。若最后修改時間較新，說明資源又被改動過，則響應(yīng)整片資源內(nèi)容（寫在響應(yīng)消息包體內(nèi)），包括更新Last-Modified的值，HTTP 200；若最后修改時間較舊，說明資源無新修改，則響應(yīng)HTTP 304(無需請求，節(jié)省瀏覽)，告知瀏覽器繼續(xù)使用所保存的cache | |
校驗值 | ETag | "fd56273325a2114818df4f29a628226d" | 響應(yīng) | 告訴瀏覽器當前資源在服務(wù)器的唯一標識符（生成規(guī)則由服務(wù)器決定） |
If-None-Match | "fd56273325a2114818df4f29a628226d" | 請求 | 當資源過期時（使用Cache-Control標識的max-age），發(fā)現(xiàn)資源具有Etage聲明，則再次向web服務(wù)器請求時帶上頭If-None-Match（Etag的值）。web服務(wù)器收到請求后發(fā)現(xiàn)有頭If-None-Match則與被請求資源的相應(yīng)校驗串進行比對，決定返回200或304 |
各種類型之間的關(guān)系和區(qū)別：
并不是所有的請求都能被緩存，無法被緩存的有：
者：kevinylzhao，騰訊音樂前端開發(fā)工程師
瀏覽器緩存策略對于前端開發(fā)同學(xué)來說不陌生，大家都有一定的了解，但如果沒有系統(tǒng)的歸納總結(jié)，可能三言兩語很難說明白，甚至說錯，尤其在面試過程中感觸頗深，很多候選人對這類基礎(chǔ)知識竟然都是一知半解，說出幾個概念就沒了，所以重新歸納總結(jié)下，溫故而知新。
瀏覽器緩存一般分為兩類：強緩存（也稱本地緩存）和協(xié)商緩存（也稱弱緩存）。
瀏覽器發(fā)送請求前，會先去緩存里查看是否命中強緩存，如果命中，則直接從緩存中讀取資源，不會發(fā)送請求到服務(wù)器。否則，進入下一步。
當強緩存沒有命中時，瀏覽器一定會向服務(wù)器發(fā)起請求。服務(wù)器會根據(jù) Request Header 中的一些字段來判斷是否命中協(xié)商緩存。如果命中，服務(wù)器會返回 304 響應(yīng)，但是不會攜帶任何響應(yīng)實體，只是告訴瀏覽器可以直接從瀏覽器緩存中獲取這個資源。如果本地緩存和協(xié)商緩存都沒有命中，則從直接從服務(wù)器加載資源。
按照本地緩存階段和協(xié)商緩存階段分類：
上述代碼的作用是告訴瀏覽器當前頁面不被緩存，事實上這種禁用緩存的形式用處很有限：
a. 僅有 IE 才能識別這段 meta 標簽含義，其它主流瀏覽器僅識別“Cache-Control: no-store”的 meta 標簽。
b. 在 IE 中識別到該 meta 標簽含義，并不一定會在請求字段加上 Pragma，但的確會讓當前頁面每次都發(fā)新請求（僅限頁面，頁面上的資源則不受影響）。
在 HTTP 請求和響應(yīng)的消息報頭中，常見的與緩存有關(guān)的消息報頭有：
上圖中只是常用的消息報頭，下面來看下不同字段之間的關(guān)系和區(qū)別：
a. Last-Modified 標注的最后修改只能精確到秒級，如果某些文件在 1 秒鐘以內(nèi)，被修改多次的話，它將不能準確標注文件的新鮮度；
b. 某些文件也許會周期性的更改，但是它的內(nèi)容并不改變(僅僅改變的修改時間)，但 Last-Modified 卻改變了，導(dǎo)致文件沒法使用緩存；
c. 有可能存在服務(wù)器沒有準確獲取文件修改時間，或者與代理服務(wù)器時間不一致等情形。
瀏覽器可以在內(nèi)存、硬盤中開辟一個空間用于保存請求資源副本。我們經(jīng)常調(diào)試時在 DevTools Network 里看到 Memory Cache（內(nèi)存緩存）和 Disk Cache（硬盤緩存），指的就是緩存所在的位置。請求一個資源時，會按照優(yōu)先級（Service Worker -> Memory Cache -> Disk Cache -> Push Cache）依次查找緩存，如果命中則使用緩存，否則發(fā)起請求。這里先介紹 Memory Cache 和 Disk Cache。
200 from memory cache
表示不訪問服務(wù)器，直接從內(nèi)存中讀取緩存。因為緩存的資源保存在內(nèi)存中，所以讀取速度較快，但是關(guān)閉進程后，緩存資源也會隨之銷毀，一般來說，系統(tǒng)不會給內(nèi)存分配較大的容量，因此內(nèi)存緩存一般用于存儲較小文件。同時內(nèi)存緩存在有時效性要求的場景下也很有用（比如瀏覽器的隱私模式）。
200 from disk cache
表示不訪問服務(wù)器，直接從硬盤中讀取緩存。與內(nèi)存相比，硬盤的讀取速度相對較慢，但硬盤緩存持續(xù)的時間更長，關(guān)閉進程之后，緩存的資源仍然存在。由于硬盤的容量較大，因此一般用于存儲大文件。
下圖可清晰看出差別：
200 from prefetch cache
在 preload 或 prefetch 的資源加載時，兩者也是均存儲在 http cache，當資源加載完成后，如果資源是可以被緩存的，那么其被存儲在 http cache 中等待后續(xù)使用；如果資源不可被緩存，那么其在被使用前均存儲在 memory cache。
CDN Cache
以騰訊 CDN 為例：X-Cache-Lookup:Hit From MemCache 表示命中 CDN 節(jié)點的內(nèi)存；X-Cache-Lookup:Hit From Disktank 表示命中 CDN 節(jié)點的磁盤；X-Cache-Lookup:Hit From Upstream 表示沒有命中 CDN。
從上圖能感受到整個流程，比如常見兩種刷新場景：
IndexedDB 就是瀏覽器提供的本地數(shù)據(jù)庫，能夠在客戶端存儲可觀數(shù)量的結(jié)構(gòu)化數(shù)據(jù)，并且在這些數(shù)據(jù)上使用索引進行高性能檢索的 API。
異步 API 方法調(diào)用完后會立即返回，而不會阻塞調(diào)用線程。要異步訪問數(shù)據(jù)庫，要調(diào)用 window 對象 indexedDB 屬性的 open() 方法。該方法返回一個 IDBRequest 對象 (IDBOpenDBRequest)；異步操作通過在 IDBRequest 對象上觸發(fā)事件來和調(diào)用程序進行通信。
常用異步 API 如下：
在 16 年曾基于 IndexDB 做過一整套緩存策略，有不錯的優(yōu)化效果：
SW 從 2014 年提出的草案到現(xiàn)在已經(jīng)發(fā)展很成熟了，基于 SW 做離線緩存，讓用戶能夠進行離線體驗，消息推送體驗，離線緩存能力涉及到 Cache 和 CacheStorage 的概念，篇幅有限，不展開了。
localStorage 屬性允許你訪問一個 Document 源(origin)的對象 Storage 用于存儲當前源的數(shù)據(jù)，除非用戶人為清除(調(diào)用 localStorage api 或者清除瀏覽器數(shù)據(jù))， 否則存儲在 localStorage 的數(shù)據(jù)將被長期保留。
sessionStorage 屬性允許你訪問一個 session Storage 對象，用于存儲當前會話的數(shù)據(jù)，存儲在 sessionStorage 里面的數(shù)據(jù)在頁面會話結(jié)束時會被清除。頁面會話在瀏覽器打開期間一直保持，并且重新加載或恢復(fù)頁面仍會保持原來的頁面會話。
通過了解瀏覽器各種緩存機制和存儲能力特點，結(jié)合業(yè)務(wù)制定合適的緩存策略，善用緩存是基本功，可以用于時常審查負責的業(yè)務(wù)，可能就會發(fā)現(xiàn)個別業(yè)務(wù)并沒有運用到位，共勉。
存是個老生長談的問題，對于前端工程師來講更是我們的必修課。或許很多人會說我的項目并沒有問題，根本不需要聊什么緩存。如果真的是這樣，只能證明你前端道路才剛剛開始。
小郭今天分享緩存的原因在于：公司的一個核心APP中嵌入了SPA，而且應(yīng)用核心都分布在SPA中，功能復(fù)雜且重。問題出現(xiàn)了：應(yīng)用核心頁面打開一直處于加載狀態(tài)，排除掉弱網(wǎng)環(huán)境的原因，重點就在于沒有緩存，每次進入頁面都需要重載DOM和數(shù)據(jù)，拖慢頁面打開速度。
那應(yīng)該處理緩存問題呢？接下來小郭從三個方向來講解。
在了解瀏覽器緩存前，我們需要先了解一下相關(guān)的概念：cache-control，expires，last-Modified，ETag。
瀏覽器通過請求頭實現(xiàn)緩存，關(guān)鍵的請求頭有cache-control，expires，last-Modified，ETag等。我們從時間和空間兩個角度來看瀏覽器緩存。
時間
瀏覽器發(fā)送第一次請求：不緩存，服務(wù)端根據(jù)設(shè)定的緩存策略返回相應(yīng)的header，如：cache-control，expires，last-Modified，ETag。
瀏覽器發(fā)送第二次請求：
空間
如果緩存就按理論上設(shè)置，那就太簡單了。在實際應(yīng)用有個嚴重的問題，我們不僅要緩存代碼，還需要更新代碼。如果靜態(tài)資源名字不變，怎么讓瀏覽器即能緩存又能在有新代碼時更新。最簡單的解決方式就是靜態(tài)資源路徑添加一個版本值，版本不變就走緩存策略，版本變了就加載新資源。如下：
<script src="xx/xx.js?v=24334452"></script>然而這種處理方式在部署時有問題。
解決方法：靜態(tài)資源和頁面是分開部署
這些問題的本質(zhì)是以上的部署方式是“覆蓋式發(fā)布”，解決方式是“非覆蓋式發(fā)布”。即用靜態(tài)資源的文件摘要信息給文件命名，這樣每次更新資源不會覆蓋原來的資源，先將資源發(fā)布上去。這時候存在兩種資源，用戶用舊頁面訪問舊資源，然后再更新頁面，用戶變成新頁面訪問新資源，就能做到無縫切換。簡單來說就是給靜態(tài)文件名加hash值。
那如何實現(xiàn)呢？
現(xiàn)在前端代碼都用webpack之類的構(gòu)建工具打包，那么結(jié)合webpack該怎么做，怎么才能做到持久化緩存？
一、webpack給文件名添加hash值是很簡單的，但hash/chunkhash/contenthash要用哪個呢？
官方定義
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īng)該將它們提取出來。
第三方庫提取方式是設(shè)置optimization的splitChunks的cacheGroups。splitChunks能提取模塊，cacheGroups能緩存模塊，并且cacheGroups的配置會覆蓋splitChunks相同配置，既能提取又能緩存，故只需設(shè)置cacheGroups。
運行時代碼的提取方式為配置runtimeChunk，默認為false，表示運行時代碼嵌入到不同的chunk文件中；現(xiàn)在將運行時代碼提取出來，并命名為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編譯過程中由多個module組成的文件
bundle：bundle是chunk文件的最終狀態(tài)，是webpack編譯后的結(jié)果
一個文件被分離為3個文件，文件間怎么相互依賴的，會影響彼此打包，解決方法是將moduleId和chunkId改成按照文件路徑生成。
optimization: {
moduleIds: 'hashed',
namedModules: true,
namedChunks: true
}這樣子moduleId在編譯后的文件是文件目錄的hash值，更加安全。這也是namedChunks在production默認為false的原因，不想依賴的文件路徑在編譯后的文件直接展示，但是為了持久性緩存，這里也只能打開。
四、CSS文件緩存
當css代碼提取成單獨文件，當我們改變css時，怎么保證不影響引用它的js文件呢？配置如下：
plugins: [
new MiniCssExtractPlugin({
filename: "[contenthash].css"
})
]webpack持久化緩存目標是當且僅當該文件內(nèi)容變動才改變該文件名字的hash值
const MiniCssExtractPlugin = require("mini-css-extract-plugin");
module.exports = {
output: {
filename: [name].[contenthash].js, // 讓hash值只在內(nèi)容變動時更新
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命名，同上
})
],
}瀏覽器有其緩存機制，想要既能緩存又能在部署時沒有問題，需要給靜態(tài)文件名添加hash值。在webpack中，有些配置能讓我們實現(xiàn)持久化緩存。感興趣的同學(xué)可以自行去測試哦！
有任何問題可以在下方留言，想了解更多前端知識歡迎關(guān)注公眾號“一郭鮮”，文章也將同步于公眾號，前端學(xué)習(xí)不迷路
*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
