從制定計劃，到前后端的開發(fā)，最后到測試以及上線，歷時4個月，5173首頁前端性能優(yōu)化項目終于順利上線，并達到了預(yù)期的性能優(yōu)化目標。這次的項 目并不是改版，而是原來首頁的設(shè)計和功能不變，只做重構(gòu)和優(yōu)化。雖然項目名叫前端的性能優(yōu)化，但也并不僅僅是前端單方面的工作，要想徹底的把優(yōu)化做好，就 需要前后端的通力配合。
歷史背景

老首頁應(yīng)該是09年上線的，首頁也是各部門爭奪資源的地方，大家都想在首頁有一席之地，各部門在首頁都有各自的小豆腐塊，如果有新項目的上線，大多是 打補丁的方式，并且唯一的規(guī)范就是能保證功能正常運行，至于性能方面，那是很遙遠的事?？啾频氖情_發(fā)人員，每次有首頁的修改都是擔(dān)驚受怕的，怕改了這個那 個又出問題，歷史原因造成的問題越來越多。

最先看不下去的應(yīng)該是前端人員，因為首頁在不斷的修修補補中，性能已經(jīng)差到前端人員覺得很沒面子的地步了。但是看不下去也僅僅是看不下去，沒法采取實 質(zhì)性的措施來改善，因為這牽涉到各部門的利益，也如上面說的，優(yōu)化不僅僅在于前端，于是前端人員也只能向上面反映問題。到了今年，終于領(lǐng)導(dǎo)也看不下去了， 某領(lǐng)導(dǎo)在海外訪問我司的818和5173首頁，對比起來前者首頁很快(插播一句，818首頁前端開發(fā)人員也正是我^_^)，后者首頁很慢，差別較大。于是 在領(lǐng)導(dǎo)重視的推動下，5173首頁的前端性能優(yōu)化項目才經(jīng)過批準，開發(fā)人員終于可以放手大膽的折騰了。

問題分析

在動手前要制定計劃，制定計劃要從解決實際問題出發(fā)，先來看看老首頁的問題，這是我在制定計劃時收集的相關(guān)數(shù)據(jù)：

1、請求數(shù)過多，其中CSS外鏈數(shù)有12個，JavaScript外鏈數(shù)竟有41個;

2、頁面總體積過大，很多靜態(tài)資源都沒加gzip，動態(tài)站點的JS甚至都沒有壓縮過;

3、資源占用嚴重，在IE6下滾動頁面時CPU占用率高達80%以上，內(nèi)存泄漏也很嚴重;

4、廣告系統(tǒng)，廣告圖片都是以document.write的方式在加載，頁面堵塞的情況很嚴重;

5、頁面有7個iframe;

6、數(shù)據(jù)源接口混亂;

7、頁面加載速度過慢，有白屏現(xiàn)象，首屏完成加載很慢;

上面的數(shù)據(jù)讓你很震驚，這也說明了有很大的優(yōu)化空間。找出了問題所在，接下來才有具體的實施方向?？傊?，無論是常規(guī)的方法，亦或是奇淫技巧，目標只有三個字，“快，更快”。

具體實施

雖然粗看頁面的內(nèi)容并不是很多，但是具體到功能模塊，都是很費時費力的。我們老大有一句很經(jīng)典的話，“通常我會問面試人員一個問題，如果你獨自來做 5173首頁的前端工作，多久能完成?如果答案只有一個星期，要么是沒看過頁面，要么就是很不專業(yè)。”我就獨自花了一個多月的時間才完成首頁的前端開發(fā)工 作。下面來說說具體的實施吧。

HTML&CSS 的重構(gòu)

頁面的設(shè)計和功能沒有變動，但是HTML頁面還是要做徹底的重構(gòu)，這里我也嘗試了使用 HTML5 的新標簽來對頁面進行布局。CSS 的重構(gòu)也是理所當(dāng)然的，原來有12個外鏈的 CSS，這些都要統(tǒng)統(tǒng)干掉的，有些模塊如果不止首頁有用到，就需要模塊化，該放到公用文件就放到公用文件中，在開發(fā)的時候可以分多個模塊，然后使用 @import到一個文件中，打包發(fā)布的時候再合并成一個文件。這需要把握好一個度，即要合理利用緩存，又要避免單文件過大，同時也要做好模塊化。

老首頁有很多 CSS 選擇器過長的問題，可能一個 CSS 選擇器的組合長達6-7個也是常有的事，CSS 選擇器過長不僅僅是性能方面的影響，同時也因為 CSS 權(quán)值的關(guān)系，給后期維護帶來了很多的麻煩。應(yīng)該多使用 class 來定義選擇器，再加上 tag 選擇器的組合，最多3個選擇器的組合就能滿足絕大多數(shù)的需求了，另外在 CSS 的編寫方面禁止使用 id 選擇器和 !important，養(yǎng)成良好的 CSS 編寫習(xí)慣很重要。

JavaScript 的重構(gòu)

JavaScript的重構(gòu)太迫切了，原來竟有41個 JavaScript 外鏈文件，當(dāng)然這些外鏈也包括了15個廣告的外鏈，廣告的優(yōu)化我稍后再說，但是還剩下26個外鏈 JavaScript。這些臃腫不堪的 JavaScript文件即是造成頁面加載堵塞的元兇，也是系統(tǒng)資源占用的蛀蟲，這是整個項目的難點之一。

重新梳理了四級聯(lián)動搜索的業(yè)務(wù)邏輯，并對四級聯(lián)動搜索的交互功能做優(yōu)化，增強用戶體驗。這個模塊的 ajax 交互功能較多，最大的 JSON 數(shù)據(jù)包竟然有94.4KB，此時合理的利用當(dāng)前頁面的緩存功能($.fn.data)很重要。體積最大的 JSON 數(shù)據(jù)包在頁面 Dom Ready 后進行加載，然后拼裝第一屏的 HTML 代碼并緩存，當(dāng)用戶按字母索引選擇游戲的時候再到已加載完的 JSON 數(shù)據(jù)包中尋找相應(yīng)的數(shù)據(jù)去拼裝 HTML 代碼，然后緩存該索引的 HTML 代碼。如果接下來再選擇區(qū)、服、交易類型時，再到服務(wù)器去取相應(yīng)的 JSON 數(shù)據(jù)，拼裝成 HTML 代碼后進行緩存，此時只緩存最后一次的選擇結(jié)果。