客戶端快取分為Http快取和本地快取,使用快取好處很多,例如減少相同資料的重複傳輸,節省網路頻寬資源緩解網路瓶頸,降低了對原始伺服器的要求，避免出現過載，這樣伺服器可以更快響應其他的請求
Http快取
http快取分文強制快取和協商快取,主要用來在客戶端儲存一些不經常變化的的靜態檔案,像圖片、CSS、JS等。在講強制快取和協商快取之前,先了解一下Http快取的過程:
強制快取
瀏覽器在請求某一個資源時,會先獲取資源的header資訊,判斷是否命中強快取（cache-control和expires資訊）,若命中,則直接從快取中獲取資源資訊,包括header資訊,本次請求就不會與伺服器通訊。
快取方案
Expires：Expires(/ɪkˈspaɪərz/),到期的意思,response header裡的過期時間，瀏覽器再次載入資源時，如果在這個過期時間內，則命中強快取。
Cache-Control：當值設為max-age=300時，則代表在這個請求正確返回時間（瀏覽器也會記錄下來）的5分鐘內再次載入資源，就會命中強快取。
Cache-Control與Expires的作用一致，都是指明當前資源的有效期，控制瀏覽器是否直接從瀏覽器快取取資料還是重新發請求到伺服器取資料。只不過Cache-Control的選擇更多，設定更細緻，如果同時設定的話，其優先順序高於Expires
cache-control除了該欄位外，還有下面幾個比較常用的設定值：
public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age等等
各個訊息中的指令含義如下：
Public指示響應可被任何快取區快取。
Private指示對於單個使用者的整個或部分響應訊息，不能被共享快取處理。這允許伺服器僅僅描述當使用者的部分響應訊息，此響應訊息對於其他使用者的請求無效。
no-cache指示請求或響應訊息不能快取
no-store用於防止重要的資訊被無意的釋出。在請求訊息中傳送將使得請求和響應訊息都不使用快取。
max-age指示客戶機可以接收生存期不大於指定時間（以秒為單位）的響應。
min-fresh指示客戶機可以接收響應時間小於當前時間加上指定時間的響應。
max-stale指示客戶機可以接收超出超時期間的響應訊息。如果指定max-stale訊息的值，那麼客戶機可以接收超出超時期指定值之內的響應訊息。
協商快取
如果沒有命中強快取，瀏覽器會傳送請求到伺服器，請求會攜帶第一次返回的有關快取的header欄位資訊（Last-Modifued/If-Modified-Since和Etag/If-None-Match），由伺服器根據header資訊來比對結果是否協商快取命中。若命中，則伺服器返回新的響應header資訊更新快取中的對應header資訊，但是不返回資源內容，它會告知瀏覽器可以直接從快取獲取；否則返回最新的資源內容。
快取方案
Last-Modify/If-Modify-Since：瀏覽器第一次請求一個資源的時候，伺服器返回的header中會加上Last-Modify，Last-modify是一個時間標識該資源的最後修改時間；當瀏覽器再次請求該資源時，request的請求頭中會包含If-Modify-Since，該值為快取之前返回的Last-Modify。伺服器收到If-Modify-Since後，根據資源的最後修改時間判斷是否命中快取
Etag/If-None-Match：web伺服器響應請求時，告訴瀏覽器當前資源在伺服器的唯一標識(etag)（生成規則由伺服器決定）。當資源過期時（使用Cache-Control標識的max-age），發現資源具有Etag宣告，則再次向web伺服器請求時帶上頭If-None-Match （Etag的值）。web伺服器收到請求後發現有頭If-None-Match 則與被請求資源的相應校驗串進行比對，決定是否命中協商快取；
Last-Modified和Etag區別
Last-Modified和Etag的區別 在描述中對於Last-Modified和Etag的使用可以說是差不多的，但是，Etag(http1.1)的出現是為了解決幾個Last-Modified比較難解決的問題：
- 一些檔案也許會週期性的更改，但是他的內容並不改變(僅僅改變的修改時間)，這個時候我們並不希望客戶端認為這個檔案被修改了，而重新GET
- 某些檔案修改非常頻繁，比如在秒以下的時間內進行修改，(比方說1s內修改了N次)，If-Modified-Since能檢查到的粒度是s級的，這種修改無法判斷(或者說UNIX記錄MTIME只能精確到秒)
- 某些伺服器不能精確的得到檔案的最後修改時間 這時，利用Etag能夠更加準確的控制快取，因為Etag是伺服器自動生成或者由開發者生成的對應資源在伺服器端的唯一識別符號
Last-Modified與ETag是可以一起使用的，伺服器會優先驗證ETag，一致的情況下，才會繼續比對Last-Modified，最後才決定是否返回304。
強快取與協商快取的區別
| 獲取資源方式 | 狀態碼 | 是否傳送到伺服器 | |
|---|---|---|---|
| 強快取 | 快取中獲取 | 200(from cache) | 否,直接從快取中獲取 |
| 協商快取 | 快取中獲取 | 304(not modify) | 是,通過伺服器來告知快取是否可用 |
本地快取
本地快取和瀏覽器有很大關係,可能會出現不同的瀏覽器適用的快取技術不同,常見的本地快取:
cookie
- 1.相容所有的瀏覽器
- 2.有儲存的大小限制，一般一個源（一個域下）只能儲存4KB內容
- 3.cookie有過期時間(當然我們自己可以手動設定這個時間)
- 4.防毒軟體或者瀏覽器的垃圾清理都可能會把cookie資訊強制清除掉
- 5.在隱私或者無痕瀏覽模式下，是不記錄cookie的
- 6.cookie不是嚴格的本地儲存，因為要和伺服器之間來回傳輸
Chrome瀏覽器快取的Cookie快取
localStorage
- 1.不相容IE8及以下
- 2.也有儲存的大小限制，一個源下最多隻能儲存5MB左右
- 3.本地永久儲存，只要你不手動刪除，永遠儲存在本地（但是我們可以基於API removeItem/clear手動清除一些自己想要刪除的資訊）
- 4.防毒軟體或者瀏覽器的垃圾清理暫時不會清除localStorage（新版本谷歌瀏覽器會清除localStorage等資訊）
- 5.在隱私或者無痕瀏覽模式下，是記錄localStorage的
- 6.localStorage和伺服器沒有半毛錢關係
sessionStorage
- sessionStorage 和localStorage 唯一的區別在於sessionStorage 是臨時儲存，只對當前回話有效，當瀏覽器當前標籤頁關閉則失效，與localStorage 擁有同樣的方法。
localStorageh和sessionStorage 都只擁有大約5M的儲存空間，不適用於儲存大資料量資料。對於資料量較大的資料快取，我們應該應用本地資料庫實現（indexDB）
indexDB
IndexedDB 具有以下特點:
（1）鍵值對儲存。
IndexedDB 內部採用物件倉庫（object store）存放資料。所有型別的資料都可以直接存入，包括 JavaScript 物件。物件倉庫中，資料以"鍵值對"的形式儲存，每一個資料記錄都有對應的主鍵，主鍵是獨一無二的，不能有重複，否則會丟擲一個錯誤。
（2）非同步。
IndexedDB 操作時不會鎖死瀏覽器，使用者依然可以進行其他操作，這與 LocalStorage 形成對比，後者的操作是同步的。非同步設計是為了防止大量資料的讀寫，拖慢網頁的表現。
（3）支援事務。
IndexedDB 支援事務（transaction），這意味著一系列操作步驟之中，只要有一步失敗，整個事務就都取消，資料庫回滾到事務發生之前的狀態，不存在只改寫一部分資料的情況。
（4）同源限制
IndexedDB 受到同源限制，每一個資料庫對應建立它的域名。網頁只能訪問自身域名下的資料庫，而不能訪問跨域的資料庫。
（5）儲存空間大
IndexedDB 的儲存空間比 LocalStorage 大得多，一般來說不少於 250MB，甚至沒有上限。
（6）支援二進位制儲存。
IndexedDB 不僅可以儲存字串，還可以儲存二進位制資料（ArrayBuffer 物件和 Blob 物件）。
快取強制重新整理
在強制重新整理的時候瀏覽器就不在傳送IF-Modified-Since了，而會帶上
from disk cache & from memory cache
可以驗證請求是否使用了瀏覽器快取和是否傳送請求給伺服器端。
當點選連結、引入外部資源和瀏覽器的前進後退的時候。
from memory cache
字面理解是從記憶體中，其實也是字面的含義，這個資源是直接從記憶體中拿到的，不會請求伺服器一般已經載入過該資源且快取在了記憶體當中，當關閉該頁面時，此資源就被記憶體釋放掉了，再次重新開啟相同頁面時不會出現from memory cache的情況
from disk cache
是從磁碟當中取出的，也是在已經在之前的某個時間載入過該資源，不會請求伺服器但是此資源不會隨著該頁面的關閉而釋放掉，因為是存在硬碟當中的，下次開啟仍會from disk cache
不做深入研究
js指令碼，css，圖片，音視訊，字型
Age
是CDN新增的屬性表示在CDN中快取了多少秒
via
用來標識CDN快取經歷了哪些伺服器，快取是否命中，使用的協議
瀏覽器快取原則
- 首頁可以看做是框架 應該禁用快取，以保證載入的資源都是最新的
- 還有一些場景下我們希望禁用瀏覽器快取。比如輪訓api上報資料資料
- 瀏覽器快取很難徹底禁用，大家的做法是加版本號，隨機數等方法。
- 只快取200響應頭的資料，像3XX這類跳轉的頁面不需要快取。
- 對於js，css這類可以快取很久的資料，可以通過加版本號的方式更新內容
- 不需要強一致性的資料，可以快取幾秒
- 非同步載入的介面資料，可以使用ETag來校驗。
- 在伺服器新增Server頭，有利於排查錯誤
應用快取思路
分為手機APP和Client以及是否遵循http協議,在沒有聯網的狀態下可以展示資料,流量消耗過多
- 漂亮的載入過程
- 提前下發避免秒殺時同時下發資料造成流量短時間暴增
- 兜底資料 在伺服器崩潰和網路不可用的時候展示
- 臨時快取 退出即清理
- 固定快取 展示框架這種，可能很長時間不會更新，可用隨客戶端下發
- 父子連 頁面跳轉時有一部分內容不需要重新載入，可用從父選單帶過來
- 預載入 某些邏輯可用判定使用者接下來的操作，那麼可用非同步載入那些資源
- 非同步載入 先展示框架，然後非同步載入內容，避免主執行緒阻塞