建站
咨詢
售后
建站咨詢
新聞中心
瀏覽器緩存作為性能優(yōu)化的重要一環(huán)，對(duì)于前端而言，重要性不言而喻。以前總是一知半解的，所以這次好好整理總結(jié)了一下。
成都創(chuàng)新互聯(lián)2013年至今，先為門(mén)頭溝等服務(wù)建站，門(mén)頭溝等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為門(mén)頭溝企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。
1、緩存機(jī)制
首先我們來(lái)總體感知一下它的匹配流程，如下：
- 瀏覽器發(fā)送請(qǐng)求前，根據(jù)請(qǐng)求頭的expires和cache-control判斷是否命中（包括是否過(guò)期）強(qiáng)緩存策略，如果命中，直接從緩存獲取資源，并不會(huì)發(fā)送請(qǐng)求。如果沒(méi)有命中，則進(jìn)入下一步。
- 沒(méi)有命中強(qiáng)緩存規(guī)則，瀏覽器會(huì)發(fā)送請(qǐng)求，根據(jù)請(qǐng)求頭的last-modified和etag判斷是否命中協(xié)商緩存，如果命中，直接從緩存獲取資源。如果沒(méi)有命中，則進(jìn)入下一步。
- 如果前兩步都沒(méi)有命中，則直接從服務(wù)端獲取資源。
2、強(qiáng)緩存
強(qiáng)緩存：不會(huì)向服務(wù)器發(fā)送請(qǐng)求，直接從緩存中讀取資源。
2.1 強(qiáng)緩存原理
強(qiáng)制緩存就是向?yàn)g覽器緩存查找該請(qǐng)求結(jié)果，并根據(jù)該結(jié)果的緩存規(guī)則來(lái)決定是否使用該緩存結(jié)果的過(guò)程，強(qiáng)制緩存的情況主要有三種(暫不分析協(xié)商緩存過(guò)程)，如下：
- 第一次請(qǐng)求，不存在緩存結(jié)果和緩存標(biāo)識(shí)，直接向服務(wù)器發(fā)送請(qǐng)求
- 存在緩存標(biāo)識(shí)和緩存結(jié)果，但是已經(jīng)失效，強(qiáng)制緩存是啊比，則使用協(xié)商緩存（暫不分析）
- 存在該緩存結(jié)果和緩存標(biāo)識(shí)，且該結(jié)果尚未失效，強(qiáng)制緩存生效，直接返回該結(jié)果
那么強(qiáng)制緩存的緩存規(guī)則是什么？
當(dāng)瀏覽器向服務(wù)器發(fā)起請(qǐng)求時(shí)，服務(wù)器會(huì)將緩存規(guī)則放入HTTP響應(yīng)報(bào)文的HTTP頭中和請(qǐng)求結(jié)果一起返回給瀏覽器，控制強(qiáng)制緩存的字段分別是Expires和Cache-Control，其中Cache-Control優(yōu)先級(jí)比Expires高。
2.1.1、 Expires
緩存過(guò)期時(shí)間，用來(lái)指定資源到期的時(shí)間，是服務(wù)器端的具體的時(shí)間點(diǎn)。也就是說(shuō)，Expires=max-age + 請(qǐng)求時(shí)間，需要和Last-modified結(jié)合使用。Expires是Web服務(wù)器響應(yīng)消息頭字段，在響應(yīng)http請(qǐng)求時(shí)告訴瀏覽器在過(guò)期時(shí)間前瀏覽器可以直接從瀏覽器緩存取數(shù)據(jù)，而無(wú)需再次請(qǐng)求。
Expires 是 HTTP/1 的產(chǎn)物，受限于本地時(shí)間，如果修改了本地時(shí)間，可能會(huì)造成緩存失效。
2.1.2、 Cache-Control
在HTTP/1.1中，Cache-Control是最重要的規(guī)則，主要用于控制網(wǎng)頁(yè)緩存，主要取值為：
- public：所有內(nèi)容都將被緩存（客戶端和代理服務(wù)器都可緩存）
- private：所有內(nèi)容只有客戶端可以緩存，Cache-Control的默認(rèn)取值
- no-cache：客戶端緩存內(nèi)容，但是是否使用緩存則需要經(jīng)過(guò)協(xié)商緩存來(lái)驗(yàn)證決定
- no-store：所有內(nèi)容都不會(huì)被緩存，即不使用強(qiáng)制緩存，也不使用協(xié)商緩存
- max-age=xxx (xxx is numeric)：緩存內(nèi)容將在xxx秒后失效
需要注意的是，no-cache這個(gè)名字有一點(diǎn)誤導(dǎo)。設(shè)置了no-cache之后，并不是說(shuō)瀏覽器就不再緩存數(shù)據(jù)，只是瀏覽器在使用緩存數(shù)據(jù)時(shí)，需要先確認(rèn)一下數(shù)據(jù)是否還跟服務(wù)器保持一致，也就是協(xié)商緩存。而no-store才表示不會(huì)被緩存，即不使用強(qiáng)制緩存，也不使用協(xié)商緩存
2.1.3、設(shè)置
強(qiáng)緩存需要服務(wù)端設(shè)置expires和cache-control。
nginx代碼參考，設(shè)置了一年的緩存時(shí)間：
- location ~ .*\.(ico|svg|ttf|eot|woff)(.*) {
- proxy_cache pnc;
- proxy_cache_valid 200 304 1y;
- proxy_cache_valid any 1m;
- proxy_cache_lock on;
- proxy_cache_lock_timeout 5s;
- proxy_cache_use_stale updating error timeout invalid_header http_500 http_502;
- expires 1y;
- }
瀏覽器的緩存存放在哪里，如何在瀏覽器中判斷強(qiáng)制緩存是否生效？這就是下面我們要講到的from disk cache和from memory cache。
2.2、from disk cache和from memory cache
細(xì)心地同學(xué)在開(kāi)發(fā)的時(shí)候應(yīng)該注意到了Chrome的網(wǎng)絡(luò)請(qǐng)求的Size會(huì)出現(xiàn)三種情況from disk cache(磁盤(pán)緩存)、from memory cache(內(nèi)存緩存)、以及資源大小數(shù)值。
| 狀態(tài) | 類型 | 說(shuō)明 |
|---|---|---|
| 200 | form memory cache | 不請(qǐng)求網(wǎng)絡(luò)資源，資源在內(nèi)存當(dāng)中，一般腳本、字體、圖片會(huì)存在內(nèi)存當(dāng)中 |
| 200 | form disk ceche | 不請(qǐng)求網(wǎng)絡(luò)資源，在磁盤(pán)當(dāng)中，一般非腳本會(huì)存在內(nèi)存當(dāng)中，如css等 |
| 200 | 資源大小數(shù)值 | 從服務(wù)器下載最新資源 |
| 304 | 報(bào)文大小 | 請(qǐng)求服務(wù)端發(fā)現(xiàn)資源沒(méi)有更新，使用本地資源 |
瀏覽器讀取緩存的順序?yàn)閙emory –> disk。
以訪問(wèn)https://github.com/xiangxingchen/blog為例
我們第一次訪問(wèn)時(shí)https://github.com/xiangxingchen/blog
關(guān)閉標(biāo)簽頁(yè)，再此打開(kāi)https://github.com/xiangxingchen/blog時(shí)
F5刷新時(shí)
簡(jiǎn)單的對(duì)比一下
3、協(xié)商緩存
協(xié)商緩存就是強(qiáng)制緩存失效后，瀏覽器攜帶緩存標(biāo)識(shí)向服務(wù)器發(fā)起請(qǐng)求，由服務(wù)器根據(jù)緩存標(biāo)識(shí)決定是否使用緩存的過(guò)程，主要有以下兩種情況：
- 協(xié)商緩存生效，返回304和Not Modified
- 協(xié)商緩存失效，返回200和請(qǐng)求結(jié)果
3.1、Last-Modified和If-Modified-Since
瀏覽器首先發(fā)送一個(gè)請(qǐng)求，讓服務(wù)端在response header中返回請(qǐng)求的資源上次更新時(shí)間，就是last-modified，瀏覽器會(huì)緩存下這個(gè)時(shí)間。
然后瀏覽器再下次請(qǐng)求中，request header中帶上if-modified-since:[保存的last-modified的值]。根據(jù)瀏覽器發(fā)送的修改時(shí)間和服務(wù)端的修改時(shí)間進(jìn)行比對(duì)，一致的話代表資源沒(méi)有改變，服務(wù)端返回正文為空的響應(yīng)，讓瀏覽器中緩存中讀取資源，這就大大減小了請(qǐng)求的消耗。
由于last-modified依賴的是保存的絕對(duì)時(shí)間，還是會(huì)出現(xiàn)誤差的情況：
保存的時(shí)間是以秒為單位的，1秒內(nèi)多次修改是無(wú)法捕捉到的；
各機(jī)器讀取到的時(shí)間不一致，就有出現(xiàn)誤差的可能性。為了改善這個(gè)問(wèn)題，提出了使用etag。
3.2、ETag和If-None-Match
etag是http協(xié)議提供的若干機(jī)制中的一種Web緩存驗(yàn)證機(jī)制，并且允許客戶端進(jìn)行緩存協(xié)商。生成etag常用的方法包括對(duì)資源內(nèi)容使用抗碰撞散列函數(shù)，使用最近修改的時(shí)間戳的哈希值，甚至只是一個(gè)版本號(hào)。 和last-modified一樣.
瀏覽器會(huì)先發(fā)送一個(gè)請(qǐng)求得到etag的值，然后再下一次請(qǐng)求在request header中帶上if-none-match:[保存的etag的值]。
通過(guò)發(fā)送的etag的值和服務(wù)端重新生成的etag的值進(jìn)行比對(duì)，如果一致代表資源沒(méi)有改變，服務(wù)端返回正文為空的響應(yīng)，告訴瀏覽器從緩存中讀取資源。
etag能夠解決last-modified的一些缺點(diǎn)，但是etag每次服務(wù)端生成都需要進(jìn)行讀寫(xiě)操作，而last-modified只需要讀取操作，從這方面來(lái)看，etag的消耗是更大的。
二者對(duì)比
- 精確度上：Etag要優(yōu)于Last-Modified。
- 優(yōu)先級(jí)上：服務(wù)器校驗(yàn)優(yōu)先考慮Etag。
- 性能上：Etag要遜于Last-Modified
4、用戶行為對(duì)瀏覽器緩存的影響
- 打開(kāi)網(wǎng)頁(yè)，地址欄輸入地址： 查找 disk cache 中是否有匹配。如有則使用；如沒(méi)有則發(fā)送網(wǎng)絡(luò)請(qǐng)求。
- 普通刷新 (F5)：因?yàn)?TAB 并沒(méi)有關(guān)閉，因此 memory cache 是可用的，會(huì)被優(yōu)先使用(如果匹配的話)。其次才是 disk cache。
- 強(qiáng)制刷新 (Ctrl + F5)：瀏覽器不使用緩存，因此發(fā)送的請(qǐng)求頭部均帶有 Cache-control:no-cache(為了兼容，還帶了 Pragma:no-cache),服務(wù)器直接返回 200 和最新內(nèi)容。
5、總結(jié)
如果有錯(cuò)誤或者不嚴(yán)謹(jǐn)?shù)牡胤?，?qǐng)務(wù)必給予指正，十分感謝。如果喜歡或者有所啟發(fā)，歡迎star對(duì)作者也是一種鼓勵(lì)。
文章題目：瀏覽器緩存看這一篇就夠了
本文路徑：http://www.dlmjj.cn/article/djcgghc.html
