BLOGcss
網頁性能優化是一個工程學問題,理論上正確到實踐中未必合適。網頁性能優化要根據項目實際狀況來應變,沒有銀彈。
上邊 4 圖分別是請求 www.zhihu.com 80 端口和 443 端口的 Timing 圖狀況,能夠看出從鍵入網址到頁面加載完成,主要通過如下幾個階段:前端
因此優化網頁性能也應該從減小以上幾個階段的時間入手,下邊主要討論前端所能涉及到的,非前端所能改變的不會有太多說起。git
首先是最直接減小以上 5 個階段時間的方案(方案 A):github
在上邊的方案中我沒有考慮瀏覽器的並行下載能力,實際上瀏覽器是能夠同時並行下載多個資源的,可是通常瀏覽器都會對同一個域名下並行下載的資源數量做出限制,通常每一個域名容許並行下載的數量是 4-10 個(取決於瀏覽器)。那麼考慮到利用瀏覽器的並行能力,還有如下幾個點(方案 B):瀏覽器
還有一點是沒有提到的,那就是緩存,直接從本地加載纔是最快的。實際中每每會對 CSS、js、圖片等內容設置很長的緩存時間,當文件內容變動時直接修改文件名,前端的工程化使得 xx-hash.js 這種方式變得很簡單。對於一些公共的庫(好比 jQuery)使用公共的 CDN (如 bootcdn)也是不錯的方案,這樣會使得即便用戶是第一次打開你的網站也有極可能不須要再次請求。緩存
寫到這裏看起來有些亂,有些地方有矛盾,我也沒有總結相似於雅虎軍規相似的東西,仍是那一句話,沒有銀彈。把握住根源,從網絡層面的各個階段來着手,根據項目具體狀況具體分析,性能優化是須要實測的,看起來很合理的方案,實際中反而可能出現負面效果。充分利用開發者工具,如 Audits面板、Network 面板下的 Timing,他們做爲參考讓你可以容易發現拖後腿的環節,而後能夠採起針對性的方案。性能優化
同時,技術是一直在進步的,優化方案也不會一成不變,之前感受不錯的方案,未來可能會變得無效;有反作用的方案,未來可能會變成最優解。好比 HTTP/2.0 的多路複用,多路複用容許同時經過單一的 HTTP/2 鏈接發起多重的請求-響應消息,那麼方案 A 中的 2,合併文件來減小連接從而減小創建 TCP 鏈接的時間效果就再也不明顯,同時使用多個域名的 CDN 來破解瀏覽器並行數量的限制也就並不是必要了。這也提醒咱們,技術的進步可能比咱們費心的優化有效百倍。服務器
代碼層面的優化方案主要有懶加載、動態加載、預加載等方案。cookie