前端效能優化可以分為三個level：靜態資源優化、介面訪問優化、頁面渲染速度優化，在操控門檻上依次遞增，優化效果上越發沒有這麼明顯，所以很多小團隊只會做到了第一個level
追求極致的前端效能體驗，提升自己的level，come on ~
目錄
一、靜態資源優化
這個level，主要是減少靜態資源的載入時間，主要包括html、css、js和圖片檔案，靜態資源的載入時間是前端效能最大的瓶頸（特別是圖片），現如今優化的手段也很豐富，以下簡要列舉幾種常用的方法
- 合併css、js檔案，製作雪碧圖：減少http的請求次數，節省網路請求時間
- 靜態資源cdn分發：客戶端可以通過最佳的網路鏈路載入靜態資源
- js、css檔案壓縮，圖片壓縮，gzip壓縮：減少請求返回的資料量
- 靜態資源快取機制
- 權衡dns的查詢
本文旨在提供一個清晰的優化思路，上述優化方法不做具體的說明，網上也能搜尋到很多具體的教程，也可以留言、簡信一起討論
二、介面訪問優化
如果第一個level做得好，可以保證靜態資源以一個較快的速度載入出來，然而，此時情況並沒有完美，依然還存在兩個明顯的問題：
- 靜態資源載入完成了，頁面依然還在轉菊花，使用者依然還在等待。現如今web應用已經走過完全由php和jsp等後端指令碼語言渲染介面的時代，ajax非同步載入資料的方式已經成為主流，各種前端的mvc框架層出不窮，先載入靜態資源，在執行js中的ajax請求到後臺請求資料，重新渲染介面已經是一種通行的方案，這樣便出現了靜態資源載入完成，頁面可見，然而使用者還需要等待請求資料的進度條的情況（特別是介面訪問速度慢的時候）
- 使用者點選任意一個按鈕，進度條載入了半天，也沒有響應。很多複雜的功能需要並行或者序列的請求很多介面才能完成，前端的網路狀況稍微差一點，給與使用者的體驗都極差。
以上兩個問題在網路情況優異，介面請求速度快的情況下都不是問題，然而終端如果是一個手機，常常連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，這是理解以上三個維度的意義所在
乾貨不斷，歡迎關注本專欄~~~