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