瀏覽器第一次向伺服器發起該請求後拿到請求結果後,將請求結果和快取標識存入瀏覽器快取,瀏覽器對於快取的處理是根據第一次請求資源時返回的響應頭來確定的。
瀏覽器中的快取作用分為兩種情況，一種是需要傳送http請求，一種是不需要傳送。
expires：
即過期時間（expires=max-age +請求時間），存在於服務端返回的響應頭中，告訴瀏覽器在這個過期時間之前可以直接從快取裡面獲取資料，無需再次請求
expires: wed, 22 nov 2019 08:41:00 gmtcache-control：
它和expires本質的不同在於它並沒有採用具體的過期時間點這個方式，而是採用過期時長來控制快取，對應的字段是max-age。expires和cache-control同時存在的時候，cache-control會優先考慮。比如這個例子:
協商快取就是強制快取失效後,瀏覽器攜帶快取標識向伺服器發起請求,由伺服器根據快取標識決定是否使用快取的過程,主要有以下兩種情況：
即最後修改時間。在瀏覽器第一次給伺服器傳送請求後，伺服器會在響應頭中加上這個字段。
瀏覽器接收到後，如果再次請求，會在請求頭中攜帶if-modified-since欄位，這個欄位的值也就是伺服器傳來的最後修改時間。
伺服器拿到請求頭中的if-modified-since的字段後，其實會和這個伺服器中該資源的最後修改時間對比:
etag 是伺服器根據當前檔案的內容，給檔案生成的唯一標識，只要裡面的內容有改動，這個值就會變。伺服器通過響應頭把這個值給瀏覽器。
瀏覽器接收到etag的值，會在下次請求時，將這個值作為if-none-match這個欄位的內容，並放到請求頭中，然後發給伺服器。
伺服器接收到if-none-match後，會跟伺服器上該資源的etag進行比對:
etag與last-modified對比：
在精準度上，etag優於last-modified。優於 etag 是按照內容給資源上標識，因此能準確感知資源的變化。而 last-modified 就不一樣了，它在一些特殊的情況並不能準確感知資源變化，主要有兩種情況:
在效能上，last-modified優於etag，也很簡單理解，last-modified僅僅只是記錄乙個時間點，而 etag需要根據檔案的具體內容生成雜湊值。
另外，如果兩種方式都支援的話，伺服器會優先考慮etag。
強制快取優先於協商快取進行,若強制快取(expires和cache-control)生效則直接使用快取,若不生效則進行協商快取(last-modified / if-modified-since和etag / if-none-match),協商快取由伺服器決定是否使用快取,若協商快取失效,那麼代表該請求的快取失效,返回200,重新返回資源和快取標識,再存入瀏覽器快取中;生效則返回304,繼續使用快取。
web快取機制
在chrome的開發者工具中，在network /size一列中可以看見一些請求，如果在 這列中明確標明大小kb,b，說明這是乙個網路請求，否則一般都會明確標明：from memory cache,from disk cache和from serviceworker.
優先順序依次是：
它是記憶體中的快取，和硬碟中的快取相對。幾乎所有的網路請求資源都會被瀏覽器加入到memory cache中去，但由於數量大所以是個短期的儲存過程。當瀏覽的tab頁關閉的時候就失效了。或者乙個頁面占用的快取過多的時候會導致前面的tab快取還沒關閉就失效了。
（1）preloader
一般瀏覽器在開啟**的時候都是請求js/css，之後解析執行，然後再次解析下乙個請求這樣的穿行操作，那麼現在，能不能一邊解析js/css，一邊請求下乙個資源，這就是preloader所幹的事。memory cache機制保證了乙個頁面中若有兩個相同的請求的時候，（比如有兩個相同href的)都實際上只進行一次請求。在匹配快取的時候，除了會對他們的url進行匹配。也會對他們的型別、cors中的網域名稱規則進行校對。比如在script中快取的資源不能用在image型別的請求中，即使他們的src相同。
（2）從memory cache中獲取快取內容的時候，瀏覽器自動忽略max-age=0,no-cache這些頭部配置。因為memory cache只是短時間使用，大部分生命週期只有一次。max-size意思也就是「不要在下次瀏覽時使用」，和memory cache不衝突。如果真的不想讓乙個資源進入快取，即使一次都不想，就可以使用no-store。這樣memory cache就不會儲存它了
2、disk cache
也叫http cache，是儲存在硬碟上的快取，是持久儲存的，實際存在於檔案系統當中。允許相同資源跨會話，甚至站點進行使用。他會嚴格根據http頭部資訊進行判斷哪些資源快取，哪些可用，哪些過期了需要重新傳送請求。命中之後瀏覽器會從硬碟中去讀取資源，雖然過程會比記憶體中讀取慢但是比網路請求快很多。一般大部分的快取都是來自disk cache。
3.service worker
以上的快取機制和讀取，快取以及失效的行為都是通過瀏覽器判斷進行的，只能通過設定響應的頭部告訴瀏覽器應該做什麼。而service worker就是一種更直接的方式，這個快取是永久的，即使關閉tab或者是關閉瀏覽器都不能將其刪除。只有以下兩種情況才會將其刪除：手動呼叫api：cache.delete(resource)或者容量溢位。會被瀏覽器清除。如果service worker沒有命中，就會呼叫fetch()方法繼續獲取資源。雖然這個時候沒有命中service worker快取，用了網路請求，但是在chrome中依然會被標記為from service worker。
4.請求網路
如果前面的三個快取都沒有命中，那麼就通過網路請求的方式獲取。但是在獲取完成之後，需要處理如何將這個資源放在快取中去的問題：
根據service worker中的handle決定是否存入cache storage(額外的快取位置)。
根據http頭部的相關字段決定是否存入disk cache
memory cache 儲存乙份資源 的引用
前端之瀏覽器快取機制
很早就想梳理一下瀏覽器的快取機制了，一直沒有時間，實際是上懶啦 你知道的，人都有惰性，本大神只是個假神o o，也不例外。難得今天較為清閒，還是借鑑一下成功人的經驗，梳理一下吧，好記性不如爛筆頭，說不定哪次面試遇到了呢 在前端開發中，效能是乙個永恆的話題，沒有最好，只有更好。判斷乙個 效能好壞，乙個直...
瀏覽器快取機制
最近在準備優化日誌請求時遇到了一些令人疑惑的問題，比如為什麼響應頭里出現了兩個 cache control 為什麼明明設定了 no cache 卻還是發請求，為什麼多次訪問時有時請求裡帶了 etag，有時又沒有帶？等等。後來查了一些資料以及同事親自驗證，總算對這些問題有了個清晰的理解，現在整理出來以...
瀏覽器快取機制
當我們瀏覽乙個頁面發現有異常時，通常考慮的就是書不是瀏覽器做了快取呢，按ctrl f5重新請求一次就能請求到沒有快取的頁面，這個是為什麼呢。首先，ctrl f5組合鍵重新整理頁面，那麼瀏覽器會直接向目標url傳送請求，而不再使用瀏覽器快取的資料。其次，當請求到達伺服器端依然有可能出現使用伺服器端的資...