前端性能優化的三個維度

前端性能優化可以分為三個level：靜態資源優化、接口訪問優化、頁面渲染速度優化，在操控門檻上依次遞增，優化效果上越發沒有這么明顯，所以很多小團隊只會做到了第一個level

追求極致的前端性能體驗，提升自己的level，come on ~

目錄

一、靜態資源優化

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

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

本文旨在提供一個清晰的優化思路，上述優化方法不做具體的說明，網上也能搜索到很多具體的教程，也可以留言、簡信一起討論

二、接口訪問優化

如果第一個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標簽要設置高寬：減少重繪重排

另外，新晉前端框架react，虛擬dom的渲染方案，也能極大的提升渲染速度，還沒接觸的同學還不趕緊嘗嘗鮮~~

使用一些頁面性能分析工具給自己的頁面跑分，可以幫助養成良好的編程習慣、提升編程素質，例如：WebPagetest、Yslow

總結

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

 

 

來自：http://www.jianshu.com/p/a5d9938ed60f