我是如何優化網站首頁性能的

最近接到一個任務，首頁性能優化。

目標：95分位值下

1. 看到頁面框架主體內容6s（優化前10s左右），優化提高40%

2. 看到操做詳細內容9s（優化前12s左右），優化提高25%。

側面看出咱們系統的龐大程度吧，這個不值得驕傲，項目比較悠久，歷史包袱比較沉重，後面計劃node同構方式去重構，可是現階段須要一個低成本，短期的方案去提升現有性能做爲過渡。

95分位值解釋

95分位值目前是咱們看性能指標的一個重要參考點。

舉例：收集用戶打開的時間，從快到慢排列，好比是100個用戶數據，95分位值就是取出第95個用戶的數據作統計。 50分位值就是第50我的的數據。

爲何是95%，由於跟進高T的優化經驗，95分位值的數據取點最能放大問題。50,80的取點暴露的問題不明顯。

當我把最慢的那一批人的性能優化好了，哪些快的天然就解決了。

優化難點

1. 面試常常問到的頁面優化點，例如圖片合併，js合併，css合併，js壓縮等等都已經作了。常規優化點沒有什麼空間能夠優化。

2. 代碼比較老。註釋上面都是12-13年的代碼。

3. 改動須要儘可能的少，功能點不能改，時間比較緊張，QA沒有人力支援，因此須要代碼改動比較小的狀況下（修改必須可控），不重構的狀況下挖掘優化點。

任務拆分

優化性能這種任務其實比較難制定計劃，除非經驗特別豐富。

第一步：是梳理代碼

固然也不是看全部的老業務代碼，看的重點是看各個模塊的加載邏輯，展示邏輯，看入口便可。

第二部：刪遺留代碼

大概瞭解整個首頁的初始化流程後，梳理了簡單的邏輯後，發現第一個任務，刪代碼。

梳理大概結構後，目測有大量下線功能的代碼任然遺留在系統中，以前的下線邏輯應該是僅僅屏蔽了入口，而沒有清理代碼。

因此我第一個具體的工做就是找出下線的業務代碼並將他清理，不徹底統計，清理代碼量開發環境下至少5W行。

清理代碼好處不少：

1. 減小無用代碼的初始化消耗

2. 減小靜態資源

3. 讓代碼更加清晰，減小無用代碼的干擾

刪除無用代碼實際上是個髒活，吃力不討好，刪除的代碼若是還有地方引用，那麼刪除了就是引入了一個bug。

刪除代碼這個工做又沒有什麼顯性的收益，還費工費時。其實就是一個裏子的工做，把你們看不到的地方作好。

第三部：優化初始化邏輯

儘可能讓不是徹底依賴的ajax並行，減小串行。當前系統有兩個展現模塊有串行關係。梳理業務後，找出首頁加載的默認邏輯，將串行調整成爲並行。

這裏是修改代碼的地方之一，修改越少越好，由於一旦修改多了，就很差控制了，就須要QA介入，那麼整個項目的週期就會大大延長。

第四部：ajax預取

這個是上一個項目經驗積累，在加載模塊靜態資源前，能夠並行的請求這些模塊的ajax內容。本來邏輯是，加載完畢各個模塊的靜態資源，而後模塊內部開始加載靜態資源須要的ajax。這樣就避免不了靜態資源的請求和靜態資源裏面ajax的請求造成了一個串行關係。
預取的一個明顯優點是，ajax能夠提早

節省的時間 = min(ajax請求時間，靜態資源加載時間)。

這裏是修改的另一個地方：同理，這個地方沒有業務邏輯，因此須要和業務徹底解耦着作。

第五部：優化打包合併

打包這部分難度比較大，優化空間也相對較多。
這裏分了兩部分：

一：首屏不展現部分按需加載

目前看不少應該按需加載的內容所有都合併到了一塊兒，放在首屏加載了。例如點擊一個按鈕出來一個操做頁面彈框。其實這個彈框的代碼首屏展現是徹底不須要。

當時註釋：

代碼加起來壓縮完大概200kb左右，不必拆的太細,若是代碼達到500KB以上，再進一步考慮細拆

實際狀況是，這個部分的代碼壓縮混淆後達到了1.1MB（坑爹啊）。

這種狀況就是當初開發人員設想是美好的，後續業務開發人員沒有意識或者瞭解到當初的規定，業務愈來愈多，代碼也就愈來愈多。

這種狀況其實比較常見，由於打包合併這種實際上是儘可能對業務人員透明的，這種合併後的內容，其實在開發環境體現不出來，只有刻意的壓縮代碼和優化時才能注意到。

容易忽視的部分就是容易出現問題的地方。

二： 打包合併重複的部分刪除

仍是上面的緣由，打包合併對於開發人員和開發環境透明，很長一段時間後，會發現大量打包重複，比較明顯的就是底層依賴庫個個文件重複引用。這種不會引起bug，可是會影響首屏靜態資源的加載和靜態資源的解析。

一和二的成果很明顯：靜態資源網絡壓縮後（gz），1.9mb優化到了1.1mb，總體提高了42%。

三： 疑難散文件清理

以前優化過幾回散文件，因爲成本比較大，遺留了一些散文件。此次就是集中處理了一下，散文件實際上是比較嚴重的，一個散文件就會浪費一個請求。95分位值下，一個散文件可能就是100ms的影響。因此不要小看散文件對於性能的影響。

成果是減小5個js靜態資源請求，2個css請求。

優化感覺

這些優化本週會上線，期待數據會比較好看。若是本週效果不是很明顯，後面的優化空間其實就很是小了，暫時不考慮cdn，依賴後端這些方法，僅僅從靜態資源出發。

優化其實就是一個沒有那麼明確計劃的任務，每每有可能對着頁面一遍一遍看加載流程或者把源代碼挨個掃一遍找找感受，一個突發奇想，一個奇淫技巧，一個業務展現效果的調整就能達到。

後續看看是否達標，性能不達標的話，還會有《我是如何優化網站首頁性能的（番外篇）》。/(ㄒoㄒ)/~~

優化感覺2

優化就是細節完善，舉個例子：

1. 有時一個js散文件可能多消耗50ms，可是一旦出現10個，20個影響就疊加起來了。

2. 一個底層庫被重複打包了，可能多了幾千行，靜態資源增長了幾k，加載上可能就是幾ms，加上與解析幾ms。可是一旦重複的靜態資源多了，問題就來了。上萬行，上百K的資源都是拖慢系統的根源。不可思議我此次粗濾的清理了一下，清理了0.6MB的資源。

優化沒有止境，這一版上線後，確定還有不少遺留的地方，後續看看效果，繼續優化。

ps:最後發現本身整理完這麼多，也沒有作什麼，感受後面還需努力

博客地址

http://tangguangyao.github.io/

微信公衆號