前端開發：5173首頁前端性能優化實踐

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

歷史背景

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

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

問題分析

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

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

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

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

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

5、頁面有7個iframe;

6、數據源接口混亂;

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

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

具體實施

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

HTML&CSS 的重構

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

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

JavaScript 的重構

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

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

便民中心也同樣是首頁業務邏輯很復雜的模塊，涉及到很多的ajax交互以及表單的操作。各個TAB中的表單是根據請求的JSON數據來生成HTML結構的，原來是每次點擊TAB都會請求一次數據，然后生成HTML結構，每切換一次TAB都要請求，再生成，這真得很二。同樣的數據和結構只要請求一次，并生成一次即可，這種重復的操作是赤裸裸的浪費資源。該模塊的JavaScript原來請求的動態站點的文件，沒有做緩存也沒做過壓縮，每次頁面加載都在這里阻塞一小會。這里的服務端的數據源接口也很亂，開發人員缺乏規范化數據接口的概念。這里的諸多問題，我已無力吐槽了。最后也是重新梳理蛋痛的業務邏輯，重構代碼。

延遲加載，提升首屏的加載速度

當用戶打開一個很長的網頁時，首屏內容的加載給了最直觀的速度體驗。所以，讓首屏盡快的完成加載也是用戶衡量該頁面是否夠“快”的最主要的因素。5173的首頁，圖片基本都集中在下面的位置，讓下面的這些圖片全部都延遲加載就可以盡可能快的提升首屏的加載速度。常見的圖片延遲加載技術想必大家都不會陌生了，這里就不復述。在 TAB 內容中也同樣有很多圖片，這里也讓它們在觸發 TAB 菜單的時候再進行加載。給圖片在HTML代碼中添加固定的尺寸自然也不再話下。so easy? no!

圖片中不僅僅有業務配置的圖片，也有來自第三方廣告系統的圖片(包括首屏的輪播大圖也是此類型的)。這些廣告圖片的 URL 是一個 JavaScript 鏈接，其中包含了使用 document.write 的方式來加載廣告圖片的代碼。還有些 TAB 中包含了使用 iframe 嵌入到頁面的合作站點的內容。廣告圖片以及 iframe 都是阻塞頁面加載的元兇。

最初的想法是重新開發一套廣告系統，換一種廣告加載方式，但是開發成本太高。最后想到了使用 textarea 來延遲加載廣告和 iframe，玉伯提供的這種方法確實挺好用的。textarae 是個好東西，不論是普通的 HTML 代碼亦或是 CSS、JavaScript 代碼，都可以扔到里面去實現延遲加載。廣告圖片的優化比較麻煩，我在另一篇文章中有詳細的介紹。有了 textarea，很多內容都可以像實現圖片延遲加載那樣來實行延遲加載，在 TAB 內容中的 iframe 也可以在觸發 TAB 菜單時再去加載 iframe。

正是這些各種延遲加載內容的奇淫技巧在最大限度上提升了網頁首屏的加載速度。但是延遲加載內容帶來的副作用需要說明，對于一些比較重要的內容，需要考慮到對 SEO 的影響。

服務端的優化

前端能做得基本都說完了，再來說說服務端的優化工作吧。原來服務端提供給前端的數據源都是從各個站點過來的，前端需要跟各個部門的開發人員打交道，并且他們提供的數據源在性能上也比較慢。經過協商決定將各數據源匯總到一臺中間服務器上，前端統一從這臺中間服務器中去取數據，服務器端之間的通訊都加上一定的緩存時間，這樣就解決了數據源慢和不統一的問題。

針對頁面總體積過大的問題，代碼的重構確實能減小不少的體積，另外靜態資源一律都要添加gzip，僅僅是添加gzip，帶來的性能提升也是比較明顯的。

合理的利用瀏覽器端的緩存也是很重要的，除了登錄信息以及 cookie 的這種時效性較高的請求外，所有能添加 cache-control 的請求都加上了 max-age 的過期時間。關于瀏覽器端的緩存添加，這里有一篇比較詳細的文章 Cache them if you can。緩存的添加也會給更新帶來麻煩，所以要有相應的方法來清除緩存，給靜態資源的請求加上時間戳即可。

另外服務端這次也大膽的采用了 varnish 作為緩存加速服務器，這在國內大型網站中應該還不多見。

優化成果

做了這么多工作是時候看看優化成果了，先來看一組數據對比：

優化前后的請求數對比：

請求數的大大減少，緩解了服務器的壓力，可以撤掉很多服務器了。

優化前后的靜態資源的文件體積對比，沒有包含ajax數據等其他文件體積：

從文件體積的對比來看，優化后節省了494KB的下載量，假若按照日PV1000000(估值，實際值遠大于該值，實際值不便透露)來進行計算，那么每天就可以節省流量470GB。

優化前后的加載時間對比，這是在同樣的網絡環境下同時測試了淘寶和拍拍來進行對比，測試軟件為基于 IE9 的 webWatch，每次測試都是清除緩存，分多次測試得到的一個平均值：

關于加載速度的分析，淘寶和拍拍的首屏的圖片較多，所以首屏的速度快，但是總加載時間要長很多，當然他們的下載量也要大很多，5173的首屏是DOM數較多，下載量也小很多，所以總時間和首屏時間相當接近。這里說得總下載量是頁面初次加載完成的總下載量，由于都用到延遲加載技術，向下滾動時又會有圖片加載，這些時間是不計算在內的。

到底應該如何來衡量網頁加載的快慢?此次的優化我沒有用 yslow 和 pagespeed 等測試分數的軟件，而是以實際的加載速度為優化的目標，首屏的加載速度提升就是最符合實際的說明。如果一個網站打開半天還是白屏，相信大多數人都會覺得很慢。這就是實際的體驗，測分軟件是反映不出來的。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]