前端性能優化-緩存(部分)

時間 2020-04-20

原文原文鏈接

前言

面試中咱們常常會遇到前端性能如何優化緩存方面的知識,對於咱們而言,咱們經常是一籌莫展。下面來詳細介紹緩存及如何利用這方面的知識.css

CDN 緩存

看到一個形象的比喻，來比喻CDN。前端

10年前，尚未火車票代售點一說，12306.cn更是無從提及。那時候火車票還只能在火車站的售票大廳購買，而我所在的小縣城並不通火車，火車票都要去市裏的火車站購買，而從我家到縣城再到市裏，來回就是4個小時車程，簡直就是浪費生命。後來就行了，小縣城裏出現了火車票代售點，甚至鄉鎮上也有了代售點，能夠直接在代售點購買火車票，方便了很多，全市人民不再用在一個點苦逼的排隊買票了。jquery

CDN就能夠理解爲分佈在每一個縣城或者鄉鎮的火車票代售點，用戶在瀏覽網站的時候，CDN會選擇一個離用戶最近的CDN邊緣節點來響應用戶的請求，這樣海南移動用戶的請求就不會千里迢迢跑到北京電信機房的服務器（假設源站部署在北京電信機房）上了。面試

在未接入CDN 以前，用戶使用瀏覽器訪問服務的時候，相互交互的過程以下圖所示。瀏覽器

用戶在第一次訪問網站服務器的時候，瀏覽器會從服務器獲取全部的資源，在傳輸過程當中，瀏覽器會經過一些約定好的響應頭，從而肯定是否須要將這個資源保存一份到本地做爲緩存。當用戶第二次訪問該網站的時候，瀏覽器就會優先從緩存中加載資源，不用向服務器請求資源，從而提升了網站的訪問速度。緩存

例如咱們第一次訪問一個網站，下面就是瀏覽器加載資源的快照，能夠看到 5.6MB 的數據被傳輸到本地。服務器

在刷新後，咱們能夠看到傳輸數據降到了 9.9KB，在使用了緩存以後，瀏覽器不用再下載所有的文件，減小了下載量也就意味着提升了頁面加載的速度。網絡

經過上面的例子，能夠直觀地觀察到瀏覽器緩存對解決網絡延遲起到的做用是很是明顯的。

而對於一些用戶訪問量巨大的網站而言，若是全部用戶都去服務器請求數據，服務器會很快崩潰，而且在不一樣網絡以及不一樣地區的用戶，請求服務器的速度也不同。爲了提升這部分用戶的訪問速度，CDN 中又提出了新的網絡架構，即建立一些最接近用戶網絡的邊緣服務器，而後將文件緩存在這些邊緣服務器（節點）上，這就是 CDN 緩存。架構

CDN的優點很明顯：（1）CDN節點解決了跨運營商和跨地域訪問的問題，訪問延時大大下降；（2）大部分請求在CDN邊緣節點完成，CDN起到了分流做用，減輕了源站的負載。前端性能

關於CDN緩存，在瀏覽器本地緩存失效後，瀏覽器會向CDN邊緣節點發起請求。相似瀏覽器緩存，CDN邊緣節點也存在着一套緩存機制。CDN邊緣節點緩存策略因服務商不一樣而不一樣，但通常都會遵循http標準協議，經過http響應頭中的 Cache-control: max-age 的字段來設置CDN邊緣節點數據緩存時間。

當客戶端向CDN節點請求數據時，CDN節點會判斷緩存數據是否過時，若緩存數據並無過時，則直接將緩存數據返回給客戶端；不然，CDN節點就會向源站發出回源請求，從源站拉取最新數據，更新本地緩存，並將最新數據返回給客戶端。 CDN服務商通常會提供基於文件後綴、目錄多個維度來指定CDN緩存時間，爲用戶提供更精細化的緩存管理。

CND 緩存刷新

CDN邊緣節點對開發者是透明的，相比於瀏覽器Ctrl+F5的強制刷新來使瀏覽器本地緩存失效，開發者能夠經過CDN服務商提供的「刷新緩存」接口來達到清理CDN邊緣節點緩存的目的。這樣開發者在更新數據後，可使用「刷新緩存」功能來強制CDN節點上的數據緩存過時，保證客戶端在訪問時，拉取到最新的數據。

瀏覽器緩存

簡單來講,瀏覽器緩存其實就是瀏覽器保存經過HTTP獲取的全部資源,是瀏覽器將網絡資源存儲在本地的一種行爲。

緩存的資源去哪裏了?

你可能會有疑問,瀏覽器存儲了資源,那它把資源存儲在哪裏呢？

memory cache

MemoryCache顧名思義，就是將資源緩存到內存中，等待下次訪問時不須要從新下載資源，而直接從內存中獲取。Webkit早已支持memoryCache。目前Webkit資源分紅兩類，一類是主資源，好比HTML頁面，或者下載項，一類是派生資源，好比HTML頁面中內嵌的圖片或者腳本連接，分別對應代碼中兩個類：MainResourceLoader和SubresourceLoader。雖然Webkit支持memoryCache，可是也只是針對派生資源，它對應的類爲CachedResource，用於保存原始數據（好比CSS，JS等），以及解碼過的圖片數據。

disk cache

DiskCache顧名思義，就是將資源緩存到磁盤中，等待下次訪問時不須要從新下載資源，而直接從磁盤中獲取，它的直接操做對象爲CurlCacheManager。

|memory cache | disk cache

相同點	只能存儲一些派生類資源文件	只能存儲一些派生類資源文件
不一樣點	退出進程時數據會被清除	退出進程時數據不會被清除
存儲資源	通常腳本、字體、圖片會存在內存當中	通常非腳本會存在內存當中，如css等

由於CSS文件加載一次就可渲染出來,咱們不會頻繁讀取它,因此它不適合緩存到內存中,可是js之類的腳本卻隨時可能會執行,若是腳本在磁盤當中,咱們在執行腳本的時候須要從磁盤取到內存中來,這樣IO開銷就很大了,有可能致使瀏覽器失去響應。

三級緩存原理 (訪問緩存優先級)

先在內存中查找,若是有,直接加載。
若是內存中不存在,則在硬盤中查找,若是有直接加載。
若是硬盤中也沒有,那麼就進行網絡請求。
請求獲取的資源緩存到硬盤和內存。

1. Cache-control: max-age

假設你的站點有引用一個腳本文件，你很是確認這個腳本文件內容五十年不變。那麼天然但願瀏覽器把這個腳本緩存起來，不用每一次都請求服務器，而後服務器再返回相同的內容。這樣可以節省帶寬開銷而且提高性能。

此時你只須要設置文件返回的HTTP頭中的Cache-Control設置爲：

Cache-Control: max-age=31536000。雖然是五十年不變，可是標準中規定max-age值最大不能超過一年，又由於是以秒爲單位，因此值爲31536000

例如這個五十年不變的腳本地址是 www.haorooms.com/never-expire.js 那麼接下來每次用戶請求這個地址時，瀏覽器都不會再向服務器發出請求，而是直接從本地的瀏覽器緩存中取。直到一年之後或者用戶手動的清除了緩存。

可是，若是這一年中的某一天你發現腳本內容必需要更改了怎麼辦？很簡單，改變請求的文件名就行了，例如never-expire-v2.js。

Cache-control: max-age 能夠控制緩存時間。以下圖：

Max-age 使用秒來計量，如：

Cache-Control:max-age=645672

指定頁面645672秒（7.47天）後過時。

注：Cache-control是http1.1的特性，可以更加精準的控制緩存

除了上面介紹的 max-age，Cache-control還有如信息:

no-cache：先不要讀取緩存中的文件,向WEB服務器請求驗證緩存是否新鮮,新鮮則使用緩存 no-store：這個字段很關鍵,它表示數據不在硬盤中臨時保存 only-if-cached：就是在客戶端有緩存時就是用客戶端的緩存,這個通常都是在無網時使用 max-stale：只要緩存的時間沒有超過它(max-stale)指定的時間,就能夠加載使用.咱們能夠在無網絡的狀況下使用 must-revalidate：做用和相同,可是更爲嚴格.每次請求都校驗緩存和服務器源文件,一致就使用緩存,不一致就拿最新 s-maxage 同 max-age，覆蓋 max-age、Expires，但僅適用於共享緩存，在私有緩存中被忽略。 public 代表響應能夠被任何對象（發送請求的客戶端、代理服務器等等）緩存。 private 代表響應只能被單個用戶（多是操做系統用戶、瀏覽器用戶）緩存，是非共享的，不能被代理服務器緩存。

2. Expires

該字段是 http1.0 時的規範，它的值爲一個絕對時間的 GMT 格式的時間字符串，好比 Expires:Mon,18 Oct 2066 23:59:59 GMT。這個時間表明着這個資源的失效時間，在此時間以前，即命中緩存。這種方式有一個明顯的缺點，因爲失效時間是一個絕對時間，因此當服務器與客戶端時間誤差較大時，就會致使緩存混亂。

注：Expires是http1.0特性，比Cache-control要早，所以有些缺陷。因爲失效時間是一個絕對時間，因此當客戶端本地時間被修改之後，服務器與客戶端時間誤差變大之後，就會致使緩存混亂。好比說，服務器時間是2018年4月19號，客戶端原本時間是2018年4月10號，可是我手動修改客戶端時間爲2018年4月20，所以服務器時間和客戶端時間有誤差以後，緩存失效，這是不對的。

以上2個緩存，遵循三級緩存原理，Cache-Control與Expires能夠在服務端配置同時啓用或者啓用任意一個，同時啓用的時候Cache-Control優先級高。