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

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

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

問題分析

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

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

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

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

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

5、頁面有7個(gè)iframe;

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

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

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

具體實(shí)施

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

HTML&CSS 的重構(gòu)

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

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

JavaScript 的重構(gòu)

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

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