前端性能優化（一）用一張圖說明載入優化

本文從載入的角度寫一下前端性能優化。

需要說明的是下面這種腦暴圖是按照從第一象限和第四象限的順序來看的。

一、載入體積優化

我們無法控制用戶的網路狀況，既然想載入速度快，那當然是能不載入就不載入，能少載入就少載入啦。

• 在http1.1時代合併代碼是很重要的一件事兒。
• uglify和壓縮無論什麼時候都重要。gzip大家都耳熟能詳，brotli有可能會有些陌生，brotli有著更高的壓縮率，Chrome早已支持（瀏覽器支持情況可查看http://caniuse.com），國內的一些雲存儲也支持。 如果瀏覽器支持你會在Accept-Encoding請求頭中看到br的字樣。返回的是brotli壓縮的消息其Content-Encoding為br。
• 圖片壓縮，以及是否做有損壓縮要結合業務實際情況來決定。
• 圖片懶載入，http1.1很明顯，再說全載入也浪費伺服器資源。基本做法是先用一個佔位的圖片（也可做成背景圖），當滾動到可視區域時再載入圖片。
• 為不同分別率提供提供不同尺寸圖片，需要圖片伺服器支持裁切做起來才比較爽。
• 如果能使用css實現優先使用css實現，一般來說這樣是對的，但不絕對。
• 減少cookie傳輸，大部分時候圖片、css、js這些資源是不需要cookie的，所以將這些資源放在一個獨立的域名下會帶來減少cookie傳輸的好處。
• 選擇合適的圖片，這個請看腦暴圖。webp作為新格式在各方面都有優勢，但存在瀏覽器兼容問題。在圖片伺服器支持轉格式的情況下可以在前端用js判斷是否支持webp並將相應參數拼接到圖片url上，實現同一圖片url根據前端需求載入不同格式。

二、緩存優化

• http協議層面的優化，請看腦暴圖，主要是一些請求頭響應頭，這些頭信息可控制瀏覽器新鮮度驗證行為。
• 工程化角度，將不容易變的資源單獨打包，有助於這類資源的長期緩存。
• Service Worker，好吧，PWA這些日子挺熱的。

三、載入距離

值得說的是，這裡不是物理上的距離，而是網路拓撲層面的距離。可能你和你鄰居的網路距離是3000公里。

• CDN，現在大家都在用，思考一個問題，CDN一定快嗎？ 答案是否定的，有可能你的寬頻運營商特別坑，你在北京訪問的是西藏的CDN節點，但是絕大部分是沒問題的。
• 如果你的頁面是在自己公司的app內使用，那麼app來幫你做預載入是很爽的，當需要打開頁面的時候可以直接在本地拿到頁面並打開，那會非常快。

四、載入順序

• 網頁現在越來越龐大了，但是優先看到的一定是首屏，如果能讓首屏非常快的出來其他資源慢慢載入是極好的。
• bigpipe，這是響應優先順序優化，用到了http層面的transfer-encoding: chunked,最早Facebook提出，適合的場景是頁面分成很多塊，每一塊的數據都單獨獲取。為啥不用js在前端主動請求？js單線程，會阻塞住。bigpipe得提一下 @i5ting ，江湖人稱狼叔，來自金剛狼，他在github上有一個項目叫做bigview，是Node.js base的bigpipe封裝，非常棒。 @蒲小花 貢獻了大量代碼。

五、載入鏈路優化

主要是httpdns，我們知道dns解釋是一個很繁瑣的過程，可能要與遠端伺服器進行很多次信息交換才能拿到IP，如果其中一個環節慢都會嚴重影響頁面打開速速。另外，如果寬頻運營商的DNS伺服器很坑，你就慘了，可能根本打不開頁面。更慘的是被劫持了，你都不知道用戶打開的是個什麼鬼東西。

針對自家app接入httpdns可以做到的是一次http請求就可以拿到IP，而且可以在app側做緩存，這樣就可以將dns解析時間縮減到0，這是一個非常爽的事兒。這也是為啥我來推動app端接入httpdns的原因。

如果各瀏覽器端都能接入httpdns，前端又幸福了很多。拋個問題，誰能推動這事兒？

六、http1.1與http2的差異

在載入方面http2有一個多路復用，很多雲存儲廠商已經支持HTTP2。

在http1.1時代我們希望請求數少，而且瀏覽器會對同一個域名所建立的鏈接數有一個限制，所以我們希望把資源分散在多台機器上。

在http2時代，請求數不是問題了，但是只有同一個域名下的資源才能使用到多路復用，所以域名要適當的做收斂。附帶的好處是，由於復用同一個鏈接，所以http慢啟動的問題就一定程度上規避了。

更多HTTP/2的介紹請查看前端性能優化（三）聊聊HTTP/2帶來的載入優化

小結

不當以及遺漏之處歡迎指出和交流。

小姜哥：前端性能優化（二）通過一個實例聊聊DOM操作優化?

zhuanlan.zhihu.com小姜哥：前端性能優化（三）聊聊HTTP/2帶來的載入優化?

zhuanlan.zhihu.com
推薦閱讀：