來源:派臣科技|時間:2018-07-22|瀏覽:次
從制定計劃,到前后端的開發(fā),最后到測試以及上線,歷時4個月,5173首頁前端性能優(yōu)化項目終于順利上線,并達(dá)到了預(yù)期的性能優(yōu)化目標(biāo)。這次的項 目并不是改版,而是原來首頁的設(shè)計和功能不變,只做重構(gòu)和優(yōu)化。雖然項目名叫前端的性能優(yōu)化,但也并不僅僅是前端單方面的工作,要想徹底的把優(yōu)化做好,就 需要前后端的通力配合。
歷史背景
老首頁應(yīng)該是09年上線的,首頁也是各部門爭奪資源的地方,大家都想在首頁有一席之地,各部門在首頁都有各自的小豆腐塊,如果有新項目的上線,大多是 打補(bǔ)丁的方式,并且唯一的規(guī)范就是能保證功能正常運行,至于性能方面,那是很遙遠(yuǎn)的事??啾频氖情_發(fā)人員,每次有首頁的修改都是擔(dān)驚受怕的,怕改了這個那 個又出問題,歷史原因造成的問題越來越多。
最先看不下去的應(yīng)該是前端人員,因為首頁在不斷的修修補(bǔ)補(bǔ)中,性能已經(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)過批準(zhǔn),開發(fā)人員終于可以放手大膽的折騰了。
問題分析
在動手前要制定計劃,制定計劃要從解決實際問題出發(fā),先來看看老首頁的問題,這是我在制定計劃時收集的相關(guān)數(shù)據(jù):
1、請求數(shù)過多,其中CSS外鏈數(shù)有12個,JavaScript外鏈數(shù)竟有41個;
2、頁面總體積過大,很多靜態(tài)資源都沒加gzip,動態(tài)站點的JS甚至都沒有壓縮過;
3、資源占用嚴(yán)重,在IE6下滾動頁面時CPU占用率高達(dá)80%以上,內(nèi)存泄漏也很嚴(yán)重;
4、廣告系統(tǒng),廣告圖片都是以document.write的方式在加載,頁面堵塞的情況很嚴(yán)重;
5、頁面有7個iframe;
6、數(shù)據(jù)源接口混亂;
7、頁面加載速度過慢,有白屏現(xiàn)象,首屏完成加載很慢;
上面的數(shù)據(jù)讓你很震驚,這也說明了有很大的優(yōu)化空間。找出了問題所在,接下來才有具體的實施方向??傊?,無論是常規(guī)的方法,亦或是奇淫技巧,目標(biāo)只有三個字,“快,更快”。
具體實施
雖然粗看頁面的內(nèi)容并不是很多,但是具體到功能模塊,都是很費時費力的。我們老大有一句很經(jīng)典的話,“通常我會問面試人員一個問題,如果你獨自來做 5173首頁的前端工作,多久能完成?如果答案只有一個星期,要么是沒看過頁面,要么就是很不專業(yè)。”我就獨自花了一個多月的時間才完成首頁的前端開發(fā)工 作。下面來說說具體的實施吧。
HTML&CSS 的重構(gòu)
頁面的設(shè)計和功能沒有變動,但是HTML頁面還是要做徹底的重構(gòu),這里我也嘗試了使用 HTML5 的新標(biāo)簽來對頁面進(jìn)行布局。CSS 的重構(gòu)也是理所當(dāng)然的,原來有12個外鏈的 CSS,這些都要統(tǒng)統(tǒng)干掉的,有些模塊如果不止首頁有用到,就需要模塊化,該放到公用文件就放到公用文件中,在開發(fā)的時候可以分多個模塊,然后使用 @import到一個文件中,打包發(fā)布的時候再合并成一個文件。這需要把握好一個度,即要合理利用緩存,又要避免單文件過大,同時也要做好模塊化。
老首頁有很多 CSS 選擇器過長的問題,可能一個 CSS 選擇器的組合長達(dá)6-7個也是常有的事,CSS 選擇器過長不僅僅是性能方面的影響,同時也因為 CSS 權(quán)值的關(guān)系,給后期維護(hù)帶來了很多的麻煩。應(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)化,增強(qiáng)用戶體驗。這個模塊的 ajax 交互功能較多,最大的 JSON 數(shù)據(jù)包竟然有94.4KB,此時合理的利用當(dāng)前頁面的緩存功能($.fn.data)很重要。體積最大的 JSON 數(shù)據(jù)包在頁面 Dom Ready 后進(jìn)行加載,然后拼裝第一屏的 HTML 代碼并緩存,當(dāng)用戶按字母索引選擇游戲的時候再到已加載完的 JSON 數(shù)據(jù)包中尋找相應(yīng)的數(shù)據(jù)去拼裝 HTML 代碼,然后緩存該索引的 HTML 代碼。如果接下來再選擇區(qū)、服、交易類型時,再到服務(wù)器去取相應(yīng)的 JSON 數(shù)據(jù),拼裝成 HTML 代碼后進(jìn)行緩存,此時只緩存最后一次的選擇結(jié)果。