[TOC] ## 緩存機制 * 協議緩存方案：利用http緩存協議頭cache-control做304緩存，或者更精確的ETAG設置依據資源的修改時間來設置緩存方案。但目前更有效或者極端的做法是利用max-expire-time，設置資源的最大緩存時間假設為1年的長緩存，更新采用非覆蓋式更新的方式是目前大公司通行的做法。這樣每次資源請求的時候都是只從客戶端緩存讀取（status:200，size:from cache），而不是還要跑一次http請求到服務器端拿到304狀態。還是以一張淘寶首頁圖片長緩存的截圖為例：  * appCache應用緩存方案：離線應用緩存是h5提供一個比較有效的離線應用方案，利用navigator.online 、window.applicationCache對象、服務器.appcache(以前是.manifest)配置文件保證在脫機下的移動web應用照常能用，如果要做數據的離線還要加上window.localStorage做離線數據的保存。 > 但App cache 有許多設計缺陷，見：[為什么app cache沒有得到大規模應用？它有哪些硬傷嗎？](https://www.zhihu.com/question/29876535) > <br> ## 頁面切片預加載方案 性能優化靜態資源維度最后一塊內容就是針對頁面，如何盡早輸出頁面模塊，減少留白時間是一個思考點。facebook應用的BigPipe方案是個很不錯的借鑒思想，還有淘寶也有首頁做了相應的切片方案，對頁面合理的分塊，在服務器和客戶端建立某種對應機制，讓各個頁面塊并行的在服務器端拼接完成并吐出來。 <br> ## CDN 用戶和服務器之間距離越遠，經過的路由器越多，延遲也就越高。使用CDN的目的之一便是解決這一問題，當然不僅僅如此，CDN還可以分擔IDC壓力。 其實我們的CDN域名一般是和我們的網站主域名不同的，大家可以看看淘寶、騰訊的官方網站，看看他們存放靜態資源的CDN域名，都是和主域名不一樣的。為什么要這么做？主要有兩個原因： 1. 便于CDN業務獨立，能夠獨立配置緩存。為了降低web壓力，CDN系統會遵循Cache-Control和Expires HTTP頭標準對改請求返回的內容進行緩存，便于后面的請求不在回源，起到加速功能。而傳統CDN（Web與CDN共用域名）的方式，需要對不同類型的文件設置相應的Cache規則或者遵循后端的HTTP頭，但這樣難以發揮CDN的最大優勢，因為動態請求回源的概率非常之大，如果訪客與源站的線路并不慢，通過CDN的請求未必快于直接請求源站的。 大型網站為了提升web性能到極致，通常緩存頭設置比較大，像谷歌JS設置一年緩存，百度首頁logo設置十年緩存，如果將靜態元素抽取出來，就可以很方便的對所有靜態元素部署規則，而不用考慮動態請求。減少規則的條數可以提升CDN的效率。 2. 拋開無用cookie，減小帶寬占用。我們都知道HTTP協議每次發送請求都會自動帶上該域名及父級域名下的cookie，但對于CSS，JS還有圖片資源，這些cookie是沒用的，反而會浪費訪客帶寬和服務器入帶寬。而我們的主站，為了保持會話或者做其他緩存，都會存放著大量的cookie，所以如果將CDN與主站域名分離，就能解決這一問題。 不過這樣一來，新的問題就出現了：CDN域名與主站域名不同，DNS解析CDN域名還需要花費額外的時間，增加網絡延遲。 這時，我們可以使用DNS Prefetch。 <br> ## HTTP2 <br> ## 參考資料 [鳥瞰前端 , 再論性能優化](https://juejin.im/post/59c2109cf265da066875eff5#comment) [網站性能優化實戰——從12.67s到1.06s的故事](https://zhuanlan.zhihu.com/p/35224473) [DNS Prefetching的兩三事](https://zhuanlan.zhihu.com/p/22362198) [ 預加載系列一：DNS Prefetching 的正確使用姿勢](https://segmentfault.com/a/1190000003944417) [ Head標簽里面的dns-prefetch，preconnect，prefetch和prerender](https://segmentfault.com/a/1190000011065339)