資訊專欄INFORMATION COLUMN
摘要：分位值解釋分位值目前是我們看性能指標的一個重要參考點。為什么是，因為跟進高的優化經驗，分位值的數據取點最能放大問題。分位值下，一個散文件可能就是的影響。
最近接到一個任務，首頁性能優化。
目標：95分位值下
看到頁面框架主體內容6s（優化前10s左右），優化提升40%
看到操作詳細內容9s（優化前12s左右），優化提升25%。
側面看出我們系統的龐大程度吧，這個不值得驕傲，項目比較悠久，歷史包袱比較沉重，后面計劃node同構方式去重構，但是現階段需要一個低成本，短時間的方案去提高現有性能作為過渡。
95分位值解釋95分位值目前是我們看性能指標的一個重要參考點。
舉例：收集用戶打開的時間，從快到慢排列，比如是100個用戶數據，95分位值就是取出第95個用戶的數據做統計。 50分位值就是第50個人的數據。
為什么是95%，因為跟進高T的優化經驗，95分位值的數據取點最能放大問題。50,80的取點暴露的問題不明顯。
當我把最慢的那一批人的性能優化好了，哪些快的自然就解決了。
優化難點面試經常問到的頁面優化點，例如圖片合并，js合并，css合并，js壓縮等等都已經做了。常規優化點沒有什么空間可以優化。
代碼比較老。注釋上面都是12-13年的代碼。
改動需要盡量的少，功能點不能改，時間比較緊張，QA沒有人力支援，所以需要代碼改動比較小的情況下（修改必須可控），不重構的情況下挖掘優化點。
任務拆分優化性能這種任務其實比較難制定計劃，除非經驗特別豐富。
第一步：是梳理代碼當然也不是看所有的老業務代碼，看的重點是看各個模塊的加載邏輯，展現邏輯，看入口即可。
第二部：刪遺留代碼大概了解整個首頁的初始化流程后，梳理了簡單的邏輯后，發現第一個任務，刪代碼。
梳理大概結構后，目測有大量下線功能的代碼任然遺留在系統中，之前的下線邏輯應該是僅僅屏蔽了入口，而沒有清理代碼。
所以我第一個具體的工作就是找出下線的業務代碼并將他清理，不完全統計，清理代碼量開發環境下至少5W行。
清理代碼好處很多：
減少無用代碼的初始化消耗
減少靜態資源
讓代碼更加清晰，減少無用代碼的干擾
刪除無用代碼其實是個臟活，吃力不討好，刪除的代碼如果還有地方引用，那么刪除了就是引入了一個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優化就是細節完善，舉個例子：
有時一個js散文件可能多消耗50ms，但是一旦出現10個，20個影響就疊加起來了。
一個底層庫被重復打包了，可能多了幾千行，靜態資源增加了幾k，加載上可能就是幾ms，加上與解析幾ms。但是一旦重復的靜態資源多了，問題就來了。上萬行，上百K的資源都是拖慢系統的根源。難以想象我這次粗濾的清理了一下，清理了0.6MB的資源。
優化沒有止境，這一版上線后，肯定還有很多遺留的地方，后續看看效果，繼續優化。
ps:最后發現自己整理完這么多，也沒有做什么，感覺后面還需努力
博客地址http://tangguangyao.github.io/
微信公眾號文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/78788.html
摘要：大家好，我是冰河有句話叫做投資啥都不如投資自己的回報率高。馬上就十一國慶假期了，給小伙伴們分享下，從小白程序員到大廠高級技術專家我看過哪些技術類書籍。 大家好，我是...
摘要：在我是如何優化網站首頁性能的一篇文章中提到過分位值的概念。性能分位值分位值在月號和月，號都有一些抖動，但是不是特別明顯。分位值意義第一點從上面圖中可以看出，在性能統計中，分位值的波動最明顯，能夠放大問題。 在我是如何優化網站首頁性能的一篇文章中提到過95分位值的概念。下面從最近實際數據看看95分位值對于性能優化的參考價值。 真實數據 最近優化有了一些效果，就正好借著具體的實例數據來看看...
摘要：前端切圖神器前端掘金安裝前端的基礎工作就是把設計師的設計稿還原成前端頁面，所以切圖是作為一個前端的基本技能。 騰訊 Web 工程師的前端書單 - 閱讀 - 掘金作者：link 2014年一月以來，自己接觸web前端開發已經兩年多了，記錄一下自己前端學習路上看過的，以及道聽途說的一些書，基本上按照由淺入深來介紹。 JavaScript 入門 《JavaScript權威指南（第六版）》 ★...
閱讀 3043·2021-11-25 09:43
閱讀 1626·2021-11-24 11:15
閱讀 2359·2021-11-22 15:25
閱讀 3501·2021-11-11 16:55
閱讀 3240·2021-11-04 16:10
閱讀 2773·2021-09-14 18:02
閱讀 1685·2021-09-10 10:50
閱讀 1070·2019-08-29 15:39
