瀏覽器緩存知識小結

瀏覽器緩存基本認識

瀏覽器在加載資源時，會根據該資源的http header判斷是否命中強緩存，如命中，瀏覽器會直接在緩存加載資源，不會不會發請求到服務器。如無命中，則會發送請求給服務器，看是否命中協商緩存，但不會返回資源的數據，而是告訴客戶端能夠直接從緩存中加載這個資源，因而瀏覽器就又會從本身的緩存中去加載這個資源；當協商緩存也沒有命中的時候，瀏覽器直接從服務器加載資源數據。

瀏覽器緩存分爲強緩存和協商緩存：

強緩存：Expires、Cacha-Control；

協商緩存：If-Modified-Since、Last-Modified，ETag、If-None-Match；

強緩存的原理

Expires是http1.0提出的一個表示資源過時時間的header，它描述的是一個絕對時間，由服務器返回，用GMT格式的字符串表示，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT。

Cache-Control描述的是一個相對時間，在進行緩存命中的時候，都是利用客戶端時間進行判斷，因此相比較Expires，Cache-Control的緩存管理更有效，安全一些。（Expires是較老的強緩存管理header，因爲它是服務器返回的一個絕對時間，在服務器時間與客戶端時間相差較大時，緩存管理容易出現問題，好比隨意修改下客戶端時間，就能影響緩存命中的結果。因此在http1.1的時候，提出了一個新的header，就是Cache-Control，這是一個相對時間，在配置緩存的時候，以秒爲單位，用數值表示，如：Cache-Control:max-age=315360000）

 

【注意】強緩存是前端性能優化最有力的工具，沒有之一，對於有大量靜態資源的網頁，必定要利用強緩存，提升響應速度。

協商緩存的原理

 

【Last-Modified，If-Modified-Since】都是根據服務器時間返回的header，通常來講，在沒有調整服務器時間和篡改客戶端緩存的狀況下，這兩個header配合起來管理協商緩存是很是可靠的，可是有時候也會服務器上資源其實有變化，可是最後修改時間卻沒有變化的狀況，而這種問題又很不容易被定位出來，而當這種狀況出現的時候，就會影響協商緩存的可靠性。因此就有了另一對header來管理協商緩存，這對header就是【ETag、If-None-Match】。

 

【ETag、If-None-Match】經過瀏覽器生成的惟一標識，只要資源有變化這個串就不一樣，跟最後修改時間沒有關係，因此能很好的補充Last-Modified的問題。