[TOC] ## 突破單線程解析渲染阻塞限制 瀏覽器是一個單線程解析模式去解析渲染從服務器端拿到的html文本，css加載的過程中會對后續的腳本資源加載造成阻塞，腳本的加載也會阻塞后續DOM結構的解析造成頁面的留白時間增長，雅虎的35條軍規中有一條就是樣式文件放在頭部，腳本文件放在DOM節點最末尾，減少阻塞。 這里還有幾個針對腳本文件的優化： * 針對不需要DOM操作（主要考慮是需要操作DOM的腳本往往需要獲取一些樣式信息）的Js腳本可以采用動態創建script的方式載入，動態載入的腳本不阻塞后續資源的加載。 * 腳本文件加載可以加上defer或者async屬性標識防止阻塞 ## 避開Cookie性能bug Cookie是前端作為前后臺登錄態校驗最通常用的緩存方案，但鑒于瀏覽器在每次都會往同域的任何資源的http請求中自動帶上cookie信息的情況，這里有必要進行優化一下，因為像css、js、image這些資源請求是不需要cookie信息的，會無端造成請求帶寬的浪費（想象一下我們的cookie大小假設為10K，100個請求就是近1M的大小，高并發下以我們現行網絡帶寬也是蠻大的一筆負擔了）。Cookie free性能優化方案的處理方式是CDN異域靜態資源服務器部署我們的前端css、js、image資源。 以香港跨境匯款為例  頁面路徑下的資源的請求：  CDN資源加載的請求：  ## 突破瀏覽器并發連接限制 瀏覽器針對domain,而非頁面page做并發連接限制的特性，domain hash的技術優化方案的處理方式是將資源劃分域分開部署，但因為過多的域劃分會增加多余的DNS開銷，這里通行的數量是3個以內。 ## 緩存 我們都知道，瀏覽器在向服務器發起請求前，會先查詢本地是否有相同的文件，如果有，就會直接拉取本地緩存，這和我們在后臺部屬的Redis、Memcache類似，都是起到了中間緩沖的作用，我們先看看瀏覽器處理緩存的策略：  這里我們可以使用chrome devtools里的network面板查看網絡傳輸的相關信息： （這里需要特別注意，在我們進行緩存調試時，需要去除network面板頂部的Disable cache 勾選項，否則瀏覽器將始終不會從緩存中拉取數據） 瀏覽器默認的緩存是放在內存內的，但我們知道，內存里的緩存會因為進程的結束或者說瀏覽器的關閉而被清除，而存在硬盤里的緩存才能夠被長期保留下去。很多時候，我們在network面板中各請求的size項里，會看到兩種不同的狀態：from memory cache 和 from disk cache，前者指緩存來自內存，后者指緩存來自硬盤。而控制緩存存放位置的，不是別人，就是我們在服務器上設置的Etag字段。在瀏覽器接收到服務器響應后，會檢測響應頭部（Header），如果有Etag字段，那么瀏覽器就會將本次緩存寫入硬盤中。 之所以拉取緩存會出現200、304兩種不同的狀態碼，取決于瀏覽器是否有向服務器發起驗證請求。 只有向服務器發起驗證請求并確認緩存未被更新，才會返回304狀態碼。 首先，我們先進入nginx的配置文檔 ~~~ $ vim nginxPath/conf/nginx.conf ~~~ 在配置文檔內插入如下兩項： ~~~ etag on; //開啟etag驗證 expires 7d; //設置緩存過期時間為7天 ~~~ 打開我們的網站，在chrome devtools的network面板中觀察我們的請求資源，如果在響應頭部看見Etag和Expires字段，就說明我們的緩存配置成功了。  > 在我們配置緩存時一定要切記，瀏覽器在處理用戶請求時，如果命中強緩存，瀏覽器會直接拉取本地緩存，不會與服務器發生任何通信，也就是說，如果我們在服務器端更新了文件，并不會被瀏覽器得知，就無法替換失效的緩存。所以我們在構建階段，需要為我們的靜態資源添加md5 hash后綴，避免資源更新而引起的前后端文件無法同步的問題。 參考資料 [鳥瞰前端 , 再論性能優化](https://juejin.im/post/59c2109cf265da066875eff5#comment) [網站性能優化實戰——從12.67s到1.06s的故事](https://zhuanlan.zhihu.com/p/35224473)