最近看了一些關於前端快取的文章，很多都是概念上的規定，所以記錄一下。
首先，快取發生在瀏覽器收到伺服器的響應資料，此時，為了避免以後需要重新訪問，減少網路請求次數，就要判斷是否需要快取資料資源。這個判斷操作，前端後端都可以進行，前端的話，在html的meta裡可以設定（有些瀏覽器不支援）這段**表示啟用快取，資料有效時間為60000s，max-age, cache-control後面再說。
cache-control: max-age=60000cache-control的常用可選值有以下幾種：
需要注意兩點：
1. public， private與其他屬性值不衝突，如cache-control：public， max-age=60000。
2. no-cache， 指的是再次訪問時，不要直接使用快取，需要向伺服器驗證內容是否有效再決定是否用快取。而不是不要快取。這種方法常用於，資料經常需要更新的情況。比如部落格。（http1.0使用pagram: no-cache欄位）
剛剛提到了強快取，有強就有弱，弱快取（自己編的）被稱為協商快取或者是對比快取。我比較喜歡叫協商快取，協商快取是強快取的替補方案，只有在強快取設定的有效時間過期後，才會啟用協商快取。
協商快取也會用到兩個字段，last-modified和if-modified-since 。客戶端每次向服務端請求資源後，服務端都會把該資源的最後修改時間放在響應頭中的last-modified欄位中傳給客戶端，客戶端會把它存在快取中，當再次請求該資源時候，客戶端會把last-modified的值放在請求頭的if-modified-since欄位中傳給服務端，服務端比較這個值和該資源最後修改時間，如果相同說明該資源沒有修改，可以直接用快取，就會返回304。而不是重新再返回一遍資料，簡化了響應體的體積，也是一定程度的優化。但是如果發現值不同，那就返回200以及新的資料。 從上面的流程來看，協商快取和沒有快取（no-store）的網路請求數是一樣的，只不過返回可能會有些不同。
上面說到的last-modified存在一些問題，他只能精確到秒，如果一秒內進行多次請求，就無法識別。所以有兩個新的字段來判斷e-tag和if-none-match，e-tag表示該資源的唯一識別符號，用法和last-modified和if-modified-since相同。但是e-tag優先順序高於last-modified。
上面說了強快取和協商快取的過程，但是沒有說快取的位置，無論是強快取還是協商快取，都是儲存在disk cache，也就是硬碟的快取裡。實際上，在瀏覽器請求資源的時候，首先check的並不是disk cache，而是memory cache即記憶體的快取，記憶體的快取容量比較小，但讀取速度很快，在關掉tab的時候就會清空。
整個check流程可以歸結成醬紫：
CDN快取小結
首先，cdn可以理解為乙個普通快取，如 快取或者說邊緣快取，即便不關心使用者的具體地理位置，也應該考慮使用cdn的 快取來提高使用者體驗。簡單而言，快取會快取你 的一些頁面，通過快取來傳輸靜態內容非常的快。乙個簡單的例子 假設你有乙個帶有開始頁面的部落格，這裡面列出了所有近期的部落格列表。完成這一過...
CDN快取小結
1.為什麼使用cdn？首先，cdn可以理解為乙個普通快取，如 快取或者說邊緣快取，即便不關心使用者的具體地理位置，也應該考慮使用cdn的 快取來提高使用者體驗。簡單而言，快取會快取你 的一些頁面，通過快取來傳輸靜態內容非常的快。乙個簡單的例子 假設你有乙個帶有開始頁面的部落格，這裡面列出了所有近期的...
前端快取之HTTP快取
說真的，當自己還很小白的時候，明明修改了js的內容了，但是就是沒有載入成功，那時候感覺好神奇，好沒道理。後來知道了這是因為快取的原因。說實話，現在基於各種框架的開發，基本上沒有在業務 過程中關注快取的事情了，當然，不包括使用localstorage和cookie。今天自己學習了一些關於前端快取的東西...