摘要：分位值解釋分位值目前是我們看性能指標(biāo)的一個重要參考點(diǎn)。為什么是，因為跟進(jìn)高的優(yōu)化經(jīng)驗，分位值的數(shù)據(jù)取點(diǎn)最能放大問題。分位值下，一個散文件可能就是的影響。

最近接到一個任務(wù)，首頁性能優(yōu)化。

目標(biāo)：95分位值下

看到頁面框架主體內(nèi)容6s（優(yōu)化前10s左右），優(yōu)化提升40%

看到操作詳細(xì)內(nèi)容9s（優(yōu)化前12s左右），優(yōu)化提升25%。

側(cè)面看出我們系統(tǒng)的龐大程度吧，這個不值得驕傲，項目比較悠久，歷史包袱比較沉重，后面計劃node同構(gòu)方式去重構(gòu)，但是現(xiàn)階段需要一個低成本，短時間的方案去提高現(xiàn)有性能作為過渡。

95分位值目前是我們看性能指標(biāo)的一個重要參考點(diǎn)。

舉例：收集用戶打開的時間，從快到慢排列，比如是100個用戶數(shù)據(jù)，95分位值就是取出第95個用戶的數(shù)據(jù)做統(tǒng)計。 50分位值就是第50個人的數(shù)據(jù)。

為什么是95%，因為跟進(jìn)高T的優(yōu)化經(jīng)驗，95分位值的數(shù)據(jù)取點(diǎn)最能放大問題。50,80的取點(diǎn)暴露的問題不明顯。

當(dāng)我把最慢的那一批人的性能優(yōu)化好了，哪些快的自然就解決了。

面試經(jīng)常問到的頁面優(yōu)化點(diǎn)，例如圖片合并，js合并，css合并，js壓縮等等都已經(jīng)做了。常規(guī)優(yōu)化點(diǎn)沒有什么空間可以優(yōu)化。

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

改動需要盡量的少，功能點(diǎn)不能改，時間比較緊張，QA沒有人力支援，所以需要代碼改動比較小的情況下（修改必須可控），不重構(gòu)的情況下挖掘優(yōu)化點(diǎn)。

優(yōu)化性能這種任務(wù)其實比較難制定計劃，除非經(jīng)驗特別豐富。

當(dāng)然也不是看所有的老業(yè)務(wù)代碼，看的重點(diǎn)是看各個模塊的加載邏輯，展現(xiàn)邏輯，看入口即可。

大概了解整個首頁的初始化流程后，梳理了簡單的邏輯后，發(fā)現(xiàn)第一個任務(wù)，刪代碼。

梳理大概結(jié)構(gòu)后，目測有大量下線功能的代碼任然遺留在系統(tǒng)中，之前的下線邏輯應(yīng)該是僅僅屏蔽了入口，而沒有清理代碼。

所以我第一個具體的工作就是找出下線的業(yè)務(wù)代碼并將他清理，不完全統(tǒng)計，清理代碼量開發(fā)環(huán)境下至少5W行。

清理代碼好處很多：

減少無用代碼的初始化消耗

減少靜態(tài)資源

讓代碼更加清晰，減少無用代碼的干擾

刪除無用代碼其實是個臟活，吃力不討好，刪除的代碼如果還有地方引用，那么刪除了就是引入了一個bug。

刪除代碼這個工作又沒有什么顯性的收益，還費(fèi)工費(fèi)時。其實就是一個里子的工作，把大家看不到的地方做好。

盡量讓不是完全依賴的ajax并行，減少串行。當(dāng)前系統(tǒng)有兩個展示模塊有串行關(guān)系。梳理業(yè)務(wù)后，找出首頁加載的默認(rèn)邏輯，將串行調(diào)整成為并行。

這里是修改代碼的地方之一，修改越少越好，因為一旦修改多了，就不好控制了，就需要QA介入，那么整個項目的周期就會大大延長。

這個是上一個項目經(jīng)驗積累，在加載模塊靜態(tài)資源前，可以并行的請求這些模塊的ajax內(nèi)容。原本邏輯是，加載完畢各個模塊的靜態(tài)資源，然后模塊內(nèi)部開始加載靜態(tài)資源需要的ajax。這樣就避免不了靜態(tài)資源的請求和靜態(tài)資源里面ajax的請求形成了一個串行關(guān)系。
預(yù)取的一個明顯優(yōu)勢是，ajax可以提前

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

這里是修改的另外一個地方：同理，這個地方?jīng)]有業(yè)務(wù)邏輯，所以需要和業(yè)務(wù)完全解耦著做。

打包這部分難度比較大，優(yōu)化空間也相對較多。
這里分了兩部分：

目前看很多應(yīng)該按需加載的內(nèi)容全部都合并到了一起，放在首屏加載了。例如點(diǎn)擊一個按鈕出來一個操作頁面彈框。其實這個彈框的代碼首屏展示是完全不需要。

當(dāng)時注釋：

代碼加起來壓縮完大概200kb左右，沒必要拆的太細(xì),如果代碼達(dá)到500KB以上，再進(jìn)一步考慮細(xì)拆

實際情況是，這個部分的代碼壓縮混淆后達(dá)到了1.1MB（坑爹啊）。

這種情況就是當(dāng)初開發(fā)人員設(shè)想是美好的，后續(xù)業(yè)務(wù)開發(fā)人員沒有意識或者了解到當(dāng)初的規(guī)定，業(yè)務(wù)越來越多，代碼也就越來越多。

這種情況其實比較常見，因為打包合并這種其實是盡量對業(yè)務(wù)人員透明的，這種合并后的內(nèi)容，其實在開發(fā)環(huán)境體現(xiàn)不出來，只有刻意的壓縮代碼和優(yōu)化時才能注意到。

容易忽視的部分就是容易出現(xiàn)問題的地方。

還是上面的原因，打包合并對于開發(fā)人員和開發(fā)環(huán)境透明，很長一段時間后，會發(fā)現(xiàn)大量打包重復(fù)，比較明顯的就是底層依賴庫個個文件重復(fù)引用。這種不會引發(fā)bug，但是會影響首屏靜態(tài)資源的加載和靜態(tài)資源的解析。

一和二的成果很明顯：靜態(tài)資源網(wǎng)絡(luò)壓縮后（gz），1.9mb優(yōu)化到了1.1mb，整體提升了42%。

之前優(yōu)化過幾次散文件，由于成本比較大，遺留了一些散文件。這次就是集中處理了一下，散文件其實是比較嚴(yán)重的，一個散文件就會浪費(fèi)一個請求。95分位值下，一個散文件可能就是100ms的影響。所以不要小看散文件對于性能的影響。

成果是減少5個js靜態(tài)資源請求，2個css請求。

這些優(yōu)化本周會上線，期待數(shù)據(jù)會比較好看。如果本周效果不是很明顯，后面的優(yōu)化空間其實就非常小了，暫時不考慮cdn，依賴后端這些方法，僅僅從靜態(tài)資源出發(fā)。

優(yōu)化其實就是一個沒有那么明確計劃的任務(wù)，往往有可能對著頁面一遍一遍看加載流程或者把源代碼挨個掃一遍找找感覺，一個突發(fā)奇想，一個奇淫技巧，一個業(yè)務(wù)展示效果的調(diào)整就能達(dá)到。

后續(xù)看看是否達(dá)標(biāo)，性能不達(dá)標(biāo)的話，還會有《我是如何優(yōu)化網(wǎng)站首頁性能的（番外篇）》。/(ㄒoㄒ)/~~

優(yōu)化就是細(xì)節(jié)完善，舉個例子：

有時一個js散文件可能多消耗50ms，但是一旦出現(xiàn)10個，20個影響就疊加起來了。

一個底層庫被重復(fù)打包了，可能多了幾千行，靜態(tài)資源增加了幾k，加載上可能就是幾ms，加上與解析幾ms。但是一旦重復(fù)的靜態(tài)資源多了，問題就來了。上萬行，上百K的資源都是拖慢系統(tǒng)的根源。難以想象我這次粗濾的清理了一下，清理了0.6MB的資源。

優(yōu)化沒有止境，這一版上線后，肯定還有很多遺留的地方，后續(xù)看看效果，繼續(xù)優(yōu)化。

ps:最后發(fā)現(xiàn)自己整理完這么多，也沒有做什么，感覺后面還需努力

http://tangguangyao.github.io/