浏覽器需要定期清除浏覽器緩存?作者：kevinylzhao，騰訊音樂前端開發工程師，我來為大家科普一下關于浏覽器需要定期清除浏覽器緩存?下面希望有你要的答案，我們一起來看看吧!
作者：kevinylzhao，騰訊音樂前端開發工程師
浏覽器緩存策略對于前端開發同學來說不陌生，大家都有一定的了解，但如果沒有系統的歸納總結，可能三言兩語很難說明白，甚至說錯，尤其在面試過程中感觸頗深，很多候選人對這類基礎知識竟然都是一知半解，說出幾個概念就沒了，所以重新歸納總結下，溫故而知新。
Web 緩存是指一個 Web 資源（如 html 頁面，圖片，js，數據等）存在于 Web 服務器和客戶端（浏覽器）之間的副本。
緩存會根據進來的請求保存輸出内容的副本；當下一個請求來到的時候，如果是相同的 URL，緩存會根據緩存機制決定是直接使用副本響應訪問請求，還是向源服務器再次發送請求。
減少網絡延遲，加快頁面打開速度
減少網絡帶寬消耗
降低服務器壓力
...
新鮮度（過期機制）：也就是緩存副本有效期。一個緩存副本必須滿足以下條件，浏覽器會認為它是有效的，足夠新的：
含有完整的過期時間控制頭信息（HTTP 協議報頭），并且仍在有效期内；
浏覽器已經使用過這個緩存副本，并且在一個會話中已經檢查過新鮮度；
校驗值（驗證機制）：服務器返回資源的時候有時在控制頭信息帶上這個資源的實體标簽 Etag（Entity Tag），它可以用來作為浏覽器再次請求過程的校驗标識。如果發現校驗标識不匹配，說明資源已經被修改或過期，浏覽器需求重新獲取資源内容。
浏覽器緩存一般分為兩類：強緩存（也稱本地緩存）和協商緩存（也稱弱緩存）。
浏覽器發送請求前，會先去緩存裡查看是否命中強緩存，如果命中，則直接從緩存中讀取資源，不會發送請求到服務器。否則，進入下一步。
當強緩存沒有命中時，浏覽器一定會向服務器發起請求。服務器會根據 Request Header 中的一些字段來判斷是否命中協商緩存。如果命中，服務器會返回 304 響應，但是不會攜帶任何響應實體，隻是告訴浏覽器可以直接從浏覽器緩存中獲取這個資源。如果本地緩存和協商緩存都沒有命中，則從直接從服務器加載資源。
按照本地緩存階段和協商緩存階段分類：
使用 HTML Meta 标簽 Web 開發者可以在 HTML 頁面的節點中加入标簽，如下：
上述代碼的作用是告訴浏覽器當前頁面不被緩存，事實上這種禁用緩存的形式用處很有限：
a. 僅有 IE 才能識别這段 meta 标簽含義，其它主流浏覽器僅識别“Cache-Control: no-store”的 meta 标簽。
b. 在 IE 中識别到該 meta 标簽含義，并不一定會在請求字段加上 Pragma，但的确會讓當前頁面每次都發新請求（僅限頁面，頁面上的資源則不受影響）。
使用緩存有關的 HTTP 消息報頭 這裡需要了解 HTTP 的基礎知識。一個 URI 的完整 HTTP 協議交互過程是由 HTTP 請求和 HTTP 響應組成的。有關 HTTP 詳細内容可參考《Hypertext Transfer Protocol — HTTP/1.1》、《HTTP 權威指南》等。
在 HTTP 請求和響應的消息報頭中，常見的與緩存有關的消息報頭有：
上圖中隻是常用的消息報頭，下面來看下不同字段之間的關系和區别：
Cache-Control 與 Expires
Cache-Control：HTTP1.1 提出的特性，為了彌補 Expires 缺陷加入的，提供了更精确細緻的緩存功能。詳細了解詳細看幾個常見的指令：_ max-age：功能和 Expires 類似，但是後面跟一個以“秒”為單位的相對時間，來供浏覽器計算過期時間。_ no-cache：提供了過期驗證機制。(在 Chrome 的 devtools 中勾選 Disable cache 選項，發送的請求會去掉 If-Modified-Since 這個 Header。同時設置 Cache-Control:no-cache Pragma:no-cache，每次請求均為 200)
no-store：表示當前請求資源禁用緩存；
public：表示緩存的版本可以被代理服務器或者其他中間服務器識别；
private：表示隻有用戶自己的浏覽器能夠進行緩存，公共的代理服務器不允許緩存。
Expires：HTTP1.0 的特性，标識該資源過期的時間點，它是一個絕對值，格林威治時間（Greenwich Mean Time, GMT），即在這個時間點之後，緩存的資源過期；優先級：Cache-Control 優先級高于 Expires，為了兼容，通常兩個頭部同時設置；浏覽器默認行為：其實就算 Response Header 中沒有設置 Cache-Control 和 Expires，浏覽器仍然會緩存某些資源，這是浏覽器的默認行為，是為了提升性能進行的優化，每個浏覽器的行為可能不一緻，有些浏覽器甚至沒有這樣的優化。
Last-Modified 與 ETag
Last-Modified(Response Header)與 If-Modified-Since(Request Header)是一對報文頭，屬于 http 1.0。If-Modified-Since 是一個請求首部字段，并且隻能用在 GET 或者 HEAD 請求中。Last-Modified 是一個響應首部字段，包含服務器認定的資源作出修改的日期及時間。當帶着 If-Modified-Since 頭訪問服務器請求資源時，服務器會檢查 Last-Modified，如果 Last-Modified 的時間早于或等于 If-Modified-Since 則會返回一個不帶主體的 304 響應，否則将重新返回資源。(注意：在 Chrome 的 devtools 中勾選 Disable cache 選項後，發送的請求會去掉 If-Modified-Since 這個 Header。)
ETag 與 If-None-Match 是一對報文頭，屬于 http 1.1。ETag 是一個響應首部字段，它是根據實體内容生成的一段 hash 字符串，标識資源的狀态，由服務端産生。If-None-Match 是一個條件式的請求首部。如果請求資源時在請求首部加上這個字段，值為之前服務器端返回的資源上的 ETag，則當且僅當服務器上沒有任何資源的 ETag 屬性值與這個首部中列出的時候，服務器才會返回帶有所請求資源實體的 200 響應，否則服務器會返回不帶實體的 304 響應。
ETag 能解決什麼問題？
a. Last-Modified 标注的最後修改隻能精确到秒級，如果某些文件在 1 秒鐘以内，被修改多次的話，它将不能準确标注文件的新鮮度；
b. 某些文件也許會周期性的更改，但是它的内容并不改變(僅僅改變的修改時間)，但 Last-Modified 卻改變了，導緻文件沒法使用緩存；
c. 有可能存在服務器沒有準确獲取文件修改時間，或者與代理服務器時間不一緻等情形。
優先級：ETag 優先級比 Last-Modified 高，同時存在時會以 ETag 為準。
浏覽器可以在内存、硬盤中開辟一個空間用于保存請求資源副本。我們經常調試時在 DevTools Network 裡看到 Memory Cache（內存緩存）和 Disk Cache（硬盤緩存），指的就是緩存所在的位置。請求一個資源時，會按照優先級（Service Worker -> Memory Cache -> Disk Cache -> Push Cache）依次查找緩存，如果命中則使用緩存，否則發起請求。這裡先介紹 Memory Cache 和 Disk Cache。
200 from memory cache
表示不訪問服務器，直接從内存中讀取緩存。因為緩存的資源保存在内存中，所以讀取速度較快，但是關閉進程後，緩存資源也會随之銷毀，一般來說，系統不會給内存分配較大的容量，因此内存緩存一般用于存儲較小文件。同時内存緩存在有時效性要求的場景下也很有用（比如浏覽器的隐私模式）。
200 from disk cache
表示不訪問服務器，直接從硬盤中讀取緩存。與内存相比，硬盤的讀取速度相對較慢，但硬盤緩存持續的時間更長，關閉進程之後，緩存的資源仍然存在。由于硬盤的容量較大，因此一般用于存儲大文件。
下圖可清晰看出差别：
200 from prefetch cache
在 preload 或 prefetch 的資源加載時，兩者也是均存儲在 http cache，當資源加載完成後，如果資源是可以被緩存的，那麼其被存儲在 http cache 中等待後續使用；如果資源不可被緩存，那麼其在被使用前均存儲在 memory cache。
CDN Cache
以騰訊 CDN 為例：X-Cache-Lookup:Hit From MemCache 表示命中 CDN 節點的内存；X-Cache-Lookup:Hit From Disktank 表示命中 CDN 節點的磁盤；X-Cache-Lookup:Hit From Upstream 表示沒有命中 CDN。
從上圖能感受到整個流程，比如常見兩種刷新場景：
當 F5 刷新網頁時，跳過強緩存，但是會檢查協商緩存；
當 Ctrl F5 強制刷新頁面時，直接從服務器加載，跳過強緩存和協商緩存
IndexedDB 就是浏覽器提供的本地數據庫，能夠在客戶端存儲可觀數量的結構化數據，并且在這些數據上使用索引進行高性能檢索的 API。
異步 API 方法調用完後會立即返回，而不會阻塞調用線程。要異步訪問數據庫，要調用 window 對象 indexedDB 屬性的 open() 方法。該方法返回一個 IDBRequest 對象 (IDBOpenDBRequest)；異步操作通過在 IDBRequest 對象上觸發事件來和調用程序進行通信。
常用異步 API 如下：
在 16 年曾基于 IndexDB 做過一整套緩存策略，有不錯的優化效果：
SW 從 2014 年提出的草案到現在已經發展很成熟了，基于 SW 做離線緩存，讓用戶能夠進行離線體驗，消息推送體驗，離線緩存能力涉及到 Cache 和 CacheStorage 的概念，篇幅有限，不展開了。
localStorage 屬性允許你訪問一個 Document 源(origin)的對象 Storage 用于存儲當前源的數據，除非用戶人為清除(調用 localStorage api 或者清除浏覽器數據)， 否則存儲在 localStorage 的數據将被長期保留。
sessionStorage 屬性允許你訪問一個 session Storage 對象，用于存儲當前會話的數據，存儲在 sessionStorage 裡面的數據在頁面會話結束時會被清除。頁面會話在浏覽器打開期間一直保持，并且重新加載或恢複頁面仍會保持原來的頁面會話。
使用一緻的網址：如果您在不同的網址上提供相同的内容，将會多次獲取和存儲該内容。注意：URL 區分大小寫！
确定中繼緩存可以緩存哪些資源：對所有用戶的響應完全相同的資源很适合由 CDN 或其他中繼緩存進行緩存；
确定每個資源的最優緩存周期：不同的資源可能有不同的更新要求。審查并确定每個資源适合的 max-age；
确定網站的最佳緩存層級：對 HTML 文檔組合使用包含内容特征碼的資源網址以及短時間或 no-cache 的生命周期，可以控制客戶端獲取更新的速度；
更新最小化：有些資源的更新比其他資源頻繁。如果資源的特定部分（例如 JS 函數或一組 CSS 樣式）會經常更新，應考慮将其代碼作為單獨的文件提供。這樣，每次獲取更新時，剩餘内容（例如不會頻繁更新的庫代碼）可以從緩存中獲取，确保下載的内容量最少；
确保服務器配置或移除 ETag：因為 Etag 跟服務器配置有關，每台服務器的 Etag 都是不同的；
善用 HTML5 的緩存機制：合理設計啟用 LocalStorage、SessionStorage、IndexDB、SW 等存儲，會給頁面性能帶來明顯提升；
結合 Native 的強大存儲能力：善于利用客戶端能力，定制合适的緩存機制，打造極緻體驗。
通過了解浏覽器各種緩存機制和存儲能力特點，結合業務制定合适的緩存策略，善用緩存是基本功，可以用于時常審查負責的業務，可能就會發現個别業務并沒有運用到位，共勉。
更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!
zpostcode 
Recruit 
weather 
mreligion 
Yellowpages 
sport 
constellation 
shopping 
name 
game 
directory 
literature 
Word 
tour 
furnish 
Lottery 
tftnews 
lyrics 
News 
digital 
car 
dir 
Edu 
Finance 
