您好,登錄后才能下訂單哦!
這篇文章主要介紹了瀏覽器緩存機制是什么,具有一定借鑒價值,需要的朋友可以參考下。希望大家閱讀完這篇文章后大有收獲。下面讓小編帶著大家一起了解一下。
關(guān)于頁面性能優(yōu)化,瀏覽器緩存必定是一個繞不過的話題,判斷一個網(wǎng)站的性能最直觀的就是看網(wǎng)頁打開的速度,而提高網(wǎng)頁反應速度的一個方式就是使用緩存。一個優(yōu)秀的緩存策略可以縮短網(wǎng)頁請求資源的距離,減少延遲,并且由于緩存文件可以重復利用,還可以減少帶寬,降低網(wǎng)絡(luò)負荷。因此理解瀏覽器的緩存機制,就顯得尤為重要。
緩存在宏觀上可以分成兩類:私有緩存和共享緩存。共享緩存就是那些能被各級代理緩存的緩存。私有緩存就是用戶專享的,各級代理不能緩存的緩存。
微觀上可以分下面幾類:
緩存存在的意義就是當用戶點擊back按鈕或是再次去訪問某個頁面的時候能夠更快的響應。尤其是在多頁應用的網(wǎng)站中,如果你在多個頁面使用了一張相同的圖片,那么緩存這張圖片就變得特別的有用。瀏覽器先向代理服務(wù)器發(fā)起Web請求,再將請求轉(zhuǎn)發(fā)到源服務(wù)器。其中瀏覽器緩存包括強緩存和協(xié)商緩存,下文有詳細介紹。本文主要側(cè)重點就是針對于瀏覽器緩存。
CDN緩存一般是由網(wǎng)站管理員自己部署,為了讓他們的網(wǎng)站更容易擴展并獲得更好的性能。通常情況下,瀏覽器先向CDN網(wǎng)關(guān)發(fā)起Web請求,網(wǎng)關(guān)服務(wù)器后面對應著一臺或多臺負載均衡源服務(wù)器,會根據(jù)它們的負載請求,動態(tài)將請求轉(zhuǎn)發(fā)到合適的源服務(wù)器上。從瀏覽器角度來看,整個CDN就是一個源服務(wù)器,從這個層面來說,瀏覽器和服務(wù)器之間的緩存機制,在這種架構(gòu)下同樣適用。
代理服務(wù)器是瀏覽器和源服務(wù)器之間的中間服務(wù)器,代理轉(zhuǎn)發(fā)響應時,緩存代理會預先將資源的副本(緩存)保存到代理服務(wù)器上。當代理再次接收到對相同資源的請求時,就可以不從源服務(wù)器那里獲取資源,而是將之前緩存的資源作為響應返回。
數(shù)據(jù)庫緩存是指,當web應用的關(guān)系比較復雜,數(shù)據(jù)庫中的表很多的時候,如果頻繁進行數(shù)據(jù)庫查詢,很容易導致數(shù)據(jù)庫不堪重荷。為了提供查詢的性能,將查詢后的數(shù)據(jù)放到內(nèi)存中進行緩存,下次查詢時,直接從內(nèi)存緩存直接返回,提供響應效率。
應用層緩存是指我們在代碼層面上做的緩存。通過代碼邏輯,把曾經(jīng)請求過的數(shù)據(jù)或資源等,緩存起來,再次需要數(shù)據(jù)時通過邏輯上的處理選擇可用的緩存的數(shù)據(jù)。
瀏覽器與服務(wù)器通信的方式為應答模式,即是:瀏覽器發(fā)起HTTP請求 – 服務(wù)器響應該請求,那么瀏覽器怎么確定一個資源該不該緩存,如何去緩存呢?瀏覽器第一次向服務(wù)器發(fā)起該請求后拿到請求結(jié)果后,將請求結(jié)果和緩存標識存入瀏覽器緩存,瀏覽器對于緩存的處理是根據(jù)第一次請求資源時返回的響應頭來確定的。具體過程如下圖:
由上圖我們可以知道:
瀏覽器每次發(fā)起請求,都會先在瀏覽器緩存中查找該請求的結(jié)果以及緩存標識
瀏覽器每次拿到返回的請求結(jié)果都會將該結(jié)果和緩存標識存入瀏覽器緩存中
以上兩點結(jié)論就是瀏覽器緩存機制的關(guān)鍵,它確保了每個請求的緩存存入與讀取,只要我們再理解瀏覽器緩存的使用規(guī)則,那么所有的問題就迎刃而解了,本文也將圍繞著這點進行詳細分析。為了方便大家理解,這里我們根據(jù)是否需要向服務(wù)器重新發(fā)起HTTP請求將緩存過程分為兩個部分,分別是強緩存和協(xié)商緩存。
強緩存:不會向服務(wù)器發(fā)送請求,直接從緩存中讀取資源,在chrome控制臺的network選項中可以看到該請求返回200的狀態(tài)碼,并且size顯示from disk cache或from memory cache。
這里以我的簡書博客的請求為例,狀態(tài)碼為灰色的請求則代表使用了強制緩存,請求對應的Size值則代表該緩存存放的位置,分別為from memory cache 和 from disk cache。這里或許小伙伴會有這樣的疑惑:
from memory cache代表使用內(nèi)存中的緩存,from disk cache則代表使用的是硬盤中的緩存,瀏覽器讀取緩存的順序為memory –> disk。在瀏覽器中,瀏覽器會在js和圖片等文件解析執(zhí)行后直接存入內(nèi)存緩存中,那么當刷新頁面時只需直接從內(nèi)存緩存中讀取(from memory cache);而css文件則會存入硬盤文件中,所以每次渲染頁面都需要從硬盤讀取緩存(from disk cache)。
#### 相關(guān)的header:
public:所有內(nèi)容都將被緩存(客戶端和代理服務(wù)器都可緩存)。具體來說響應可被任何中間節(jié)點緩存,如 Browser <-- proxy1 <-- proxy2 <-- Server,中間的proxy可以緩存資源,比如下次再請求同一資源proxy1直接把自己緩存的東西給 Browser 而不再向proxy2要。
private:所有內(nèi)容只有客戶端可以緩存,Cache-Control的默認取值。具體來說,表示中間節(jié)點不允許緩存,對于Browser <-- proxy1 <-- proxy2 <-- Server,proxy 會老老實實把Server 返回的數(shù)據(jù)發(fā)送給proxy1,自己不緩存任何數(shù)據(jù)。當下次Browser再次請求時proxy會做好請求轉(zhuǎn)發(fā)而不是自作主張給自己緩存的數(shù)據(jù)。
no-cache:客戶端緩存內(nèi)容,是否使用緩存則需要經(jīng)過協(xié)商緩存來驗證決定。表示不使用 Cache-Control的緩存控制方式做前置驗證,而是使用 Etag 或者Last-Modified字段來控制緩存。需要注意的是,no-cache這個名字有一點誤導。設(shè)置了no-cache之后,并不是說瀏覽器就不再緩存數(shù)據(jù),只是瀏覽器在使用緩存數(shù)據(jù)時,需要先確認一下數(shù)據(jù)是否還跟服務(wù)器保持一致。
no-store:所有內(nèi)容都不會被緩存,即不使用強制緩存,也不使用協(xié)商緩存
max-age:max-age=xxx (xxx is numeric)表示緩存內(nèi)容將在xxx秒后失效
s-maxage(單位為s):同max-age,只用于共享緩存(比如CDN緩存)。比如當s-maxage=60時,在這60秒中,即使更新了CDN的內(nèi)容,瀏覽器也不會進行請求。max-age用于普通緩存,而s-maxage用于代理緩存。s-maxage的優(yōu)先級高于max-age。如果存在s-maxage,則會覆蓋掉max-age和Expires header。
Expires和Cache-Control兩者對比:其實這兩者差別不大,區(qū)別就在于 Expires 是http1.0的產(chǎn)物,Cache-Control是http1.1的產(chǎn)物,兩者同時存在的話,Cache-Control優(yōu)先級高于Expires;在某些不支持HTTP1.1的環(huán)境下,Expires就會發(fā)揮用處。所以Expires其實是過時的產(chǎn)物,現(xiàn)階段它的存在只是一種兼容性的寫法。
強緩存判斷是否緩存的依據(jù)來自于是否超出某個時間或者某個時間段,而不關(guān)心服務(wù)器端文件是否已經(jīng)更新,這可能會導致加載文件不是服務(wù)器端最新的內(nèi)容,那我們?nèi)绾潍@知服務(wù)器端內(nèi)容是否已經(jīng)發(fā)生了更新呢?此時我們需要用到協(xié)商緩存策略。
協(xié)商緩存就是強制緩存失效后,瀏覽器攜帶緩存標識向服務(wù)器發(fā)起請求,由服務(wù)器根據(jù)緩存標識決定是否使用緩存的過程,主要有以下兩種情況:
協(xié)商緩存生效,返回304和Not Modified
協(xié)商緩存失效,返回200和請求結(jié)果
瀏覽器在第一次訪問資源時,服務(wù)器返回資源的同時,在response header中添加 Last-Modified的header,值是這個資源在服務(wù)器上的最后修改時間,瀏覽器接收后緩存文件和header;
Last-Modified: Fri, 22 Jul 2016 01:47:00 GMT
瀏覽器下一次請求這個資源,瀏覽器檢測到有 Last-Modified這個header,于是添加If-Modified-Since這個header,值就是Last-Modified中的值;服務(wù)器再次收到這個資源請求,會根據(jù) If-Modified-Since 中的值與服務(wù)器中這個資源的最后修改時間對比,如果沒有變化,返回304和空的響應體,直接從緩存讀取,如果If-Modified-Since的時間小于服務(wù)器中這個資源的最后修改時間,說明文件有更新,于是返回新的資源文件和200
①某些服務(wù)端不能獲取精確的修改時間
②文件修改時間改了,但文件內(nèi)容卻沒有變
既然根據(jù)文件修改時間來決定是否緩存尚有不足,能否可以直接根據(jù)文件內(nèi)容是否修改來決定緩存策略?----ETag和If-None-Match
Etag是上一次加載資源時,服務(wù)器返回的response header,是對該資源的一種唯一標識,只要資源有變化,Etag就會重新生成。瀏覽器在下一次加載資源向服務(wù)器發(fā)送請求時,會將上一次返回的Etag值放到request header里的If-None-Match里,服務(wù)器只需要比較客戶端傳來的If-None-Match跟自己服務(wù)器上該資源的ETag是否一致,就能很好地判斷資源相對客戶端而言是否被修改過了。如果服務(wù)器發(fā)現(xiàn)ETag匹配不上,那么直接以常規(guī)GET 200回包形式將新的資源(當然也包括了新的ETag)發(fā)給客戶端;如果ETag是一致的,則直接返回304知會客戶端直接使用本地緩存即可。
兩者之間對比:
首先在精確度上,Etag要優(yōu)于Last-Modified。Last-Modified的時間單位是秒,如果某個文件在1秒內(nèi)改變了多次,那么他們的Last-Modified其實并沒有體現(xiàn)出來修改,但是Etag每次都會改變確保了精度;如果是負載均衡的服務(wù)器,各個服務(wù)器生成的Last-Modified也有可能不一致。
第二在性能上,Etag要遜于Last-Modified,畢竟Last-Modified只需要記錄時間,而Etag需要服務(wù)器通過算法來計算出一個hash值。
第三在優(yōu)先級上,服務(wù)器校驗優(yōu)先考慮Etag
強制緩存優(yōu)先于協(xié)商緩存進行,若強制緩存(Expires和Cache-Control)生效則直接使用緩存,若不生效則進行協(xié)商緩存(Last-Modified / If-Modified-Since和Etag / If-None-Match),協(xié)商緩存由服務(wù)器決定是否使用緩存,若協(xié)商緩存失效,那么代表該請求的緩存失效,返回200,重新返回資源和緩存標識,再存入瀏覽器緩存中;生效則返回304,繼續(xù)使用緩存。具體流程圖如下:
如果資源已經(jīng)被瀏覽器緩存下來,在緩存失效之前,再次請求時,默認會先檢查是否命中強緩存,如果強緩存命中則直接讀取緩存,如果強緩存沒有命中則發(fā)請求到服務(wù)器檢查是否命中協(xié)商緩存,如果協(xié)商緩存命中,則告訴瀏覽器還是可以從緩存讀取,否則才從服務(wù)器返回最新的資源。這是默認的處理方式,這個方式可能被瀏覽器的行為改變:
地址欄訪問,鏈接跳轉(zhuǎn)是正常用戶行為,將會觸發(fā)瀏覽器緩存機制;
F5刷新,瀏覽器會設(shè)置max-age=0,跳過強緩存判斷,會進行協(xié)商緩存判斷;
ctrl+F5刷新,跳過強緩存和協(xié)商緩存,直接從服務(wù)器拉取資源。
感謝你能夠認真閱讀完這篇文章,希望小編分享瀏覽器緩存機制是什么內(nèi)容對大家有幫助,同時也希望大家多多支持億速云,關(guān)注億速云行業(yè)資訊頻道,遇到問題就找億速云,詳細的解決方法等著你來學習!
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。