前端性能優化的三個維度

前端性能優化能夠分爲三個level：靜態資源優化、接口訪問優化、頁面渲染速度優化，在操控門檻上依次遞增，優化效果上愈加沒有這麼明顯，因此不少小團隊只會作到了第一個level
追求極致的前端性能體驗，提高本身的level，come on ~

目錄

• 1、靜態資源優化
• 2、接口訪問優化
  • 首屏直出、同構
  • 接口合併
• 3、頁面渲染速度優化
• 4、總結

1、靜態資源優化

這個level，主要是減小靜態資源的加載時間，主要包括html、css、js和圖片文件，靜態資源的加載時間是前端性能最大的瓶頸（特別是圖片），現現在優化的手段也很豐富，如下簡要列舉幾種經常使用的方法

• 合併css、js文件，製做雪碧圖：減小http的請求次數，節省網絡請求時間
• 靜態資源cdn分發：客戶端能夠經過最佳的網絡鏈路加載靜態資源
• js、css文件壓縮，圖片壓縮，gzip壓縮：減小請求返回的數據量
• 靜態資源緩存機制
• 權衡dns的查找

本文旨在提供一個清晰的優化思路，上述優化方法不作具體的說明，網上也能搜索到不少具體的教程，也能夠留言、簡信一塊兒討論

2、接口訪問優化

若是第一個level作得好，能夠保證靜態資源以一個較快的速度加載出來，然而，此時狀況並無完美，依然還存在兩個明顯的問題：

1. 靜態資源加載完成了，頁面依然還在轉菊花，用戶依然還在等待。現現在web應用已經走過徹底由php和jsp等後端腳本語言渲染界面的時代，ajax異步加載數據的方式已經成爲主流，各類前端的mvc框架層出不窮，先加載靜態資源，在執行js中的ajax請求到後臺請求數據，從新渲染界面已是一種通行的方案，這樣便出現了靜態資源加載完成，頁面可見，然而用戶還須要等待請求數據的進度條的狀況（特別是接口訪問速度慢的時候）
2. 用戶點擊任意一個按鈕，進度條加載了半天，也沒有響應。不少複雜的功能須要並行或者串行的請求不少接口才能完成，前端的網絡情況稍微差一點，給與用戶的體驗都極差。

以上兩個問題在網絡狀況優異，接口請求速度快的狀況下都不是問題，然而終端若是是一個手機，經常連wifi都不能保證，3g/4g的網絡你能期待它有多快，因此優化的潛力是巨大的

首屏直出、同構

對於上述的問題一，若是頁面的初始化數據，在後端完成渲染，其它的用戶交互使用ajax的方式完成，也就是傳統意義上的 首屏直出，就能夠獲得很好的解決

這種介於徹底後端渲染和徹底ajax渲染的方式是一個不錯的思路，可是在node出現以前，不少人寧願容忍首屏加載的菊花，也不肯意使用，爲何？由於前端和後端要維護兩套模板，使人抓狂

node出來以後，先後端都均可以使用js語言，先後端同構（前端和後臺公用模板代碼）使得首屏直出從新擁有了生存的土壤，因此同構直出如今經常相提並論，形同一個成語

react在同構直出方面作得比較出衆，更多相關知識，能夠留言、簡信討論

接口合併

一個交互須要請求多個並行或串行接口實屬正常，前端使用3g/4g等弱網絡也着實是不可抗因素，因此最好的辦法就是經過接口合併的方式來提升接口訪問速度

後臺提供的接口有其既有粒度，強行合併不合時宜，提供一個新的合併的接口也缺少機動性（前端發現一個新的合併需求，就要求後端提供一個接口，後端有開發工做量不說，還得沒完沒了的發版）

若是把接口合併的主動權交給前端，那狀況將會好不少，前端是最接近戰火的地方，最知道應該如何組合接口。基於代理服務的接口合併方案應運而生（這是本人第一個值得驕傲的原創方案，這其中還包含了node實現，想一想還有點小雞動~）

歡迎使用node實現的基於代理服務的接口合併框架，歡迎建議、拍磚，您的意見是我優化的動力

頁面渲染速度優化

在頁面不復雜、dom層次不深的狀況下，完成以上兩個level，就已經足夠了。然而在複雜的頁面上，卻還有很大的優化空間，頁面渲染速度的優化很大的程度上依託於程序員的我的編程素質，下面簡要列舉幾點：

• css放在頂部：優先渲染
• js放在底部：避免阻塞
• 減小DOM元素數量：這個最能體現變成水平了
• img標籤要設置高寬：減小重繪重排

另外，新晉前端框架 vue、react，虛擬dom的渲染方案，在內存中進行 dom diff 比較，作到最小化的操做真實的 dom （操做真實的 dom 經常會成爲性能瓶頸），能極大的提升渲染速度

使用一些頁面性能分析工具給本身的頁面跑分，能夠幫助養成良好的編程習慣、提高編程素質，例如：WebPagetest、Yslow

總結

極致的性能優化須要有清晰的step，這是理解以上三個維度的意義所在

乾貨不斷，歡迎關注本專欄~~~