年夜擬定打算，到前后端的開發，最后到測試以及上線，歷時4個月，5173首頁前端機能優化項目終于順遂上線，并達到了預期的機能優化方針。此次的項目并不是改版，而是原本首頁的設計和功能不變，只做重構和優化。雖然項目名叫前端的機能優化，但也并不僅僅是前端片面的工作，要想徹底的把優化做好，就需要前后端的通力配合。
歷史布景
老首頁應該是09年上線的，首頁也是各部門爭奪資本的處所，巨匠都想在首頁有一席之地，各部門在首頁都有各自的小豆腐塊，如不美觀有新項目的上線，年夜多是打補丁的體例，而且獨一的規范就是能保證功能正常運行，至于機能方面，那是很遙遠的事�？啾频氖情_發人員，每次有首頁的改削都是擔驚受怕的，怕改了這個阿誰又出問題，歷史原因造成的問題越來越多。
最先看不下去的應該是前端人員，因為首頁在不竭的修修補補中，機能已經差到前端人員感受很沒體面的境界了�？墒强床幌氯ヒ矁H僅是看不下去，沒法采納本色性的法子來改善，因為這牽扯到各部門的益處，也如膳縵沔說的，優化不僅僅在于前端，于是前端人員也只能向膳縵沔紡暌鉤問題。到了今年，終于率領也看不下去了，某率領在海外訪謁我司的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 的重構
恰是這些各類延遲加載內容的奇淫技巧在最年夜限度上晉升了網頁首屏的加載速度�？墒茄舆t加載內容帶來的副浸染需要聲名，對于一些斗勁主要的內容，需要考慮到對 seo 的影響。
前端能做得根基都說完了，再來說說處事端的優化工作吧。原本處事端供給給前端的數據源都是年夜各個站點過來的，前端需要跟各個部門的開發人員打交道，而且他們供給的數據源在機能上也斗勁慢。經由協商抉擇將各數據源匯總到一臺中心處事器上，前端統一年夜這臺中心處事器中去取數據，處事器端之間的通信都加上必然的緩存時刻，這樣就解決了數據源慢和不統一的問題。
年夜頭梳理了四級聯動搜索的營業邏輯，并對四級聯動搜索的交互功能做優化，增強用戶體驗。這個模塊的 ajax 交互功能較多，最年夜的 JSON 數據包竟然有94.4KB，此時合理的操作當前頁面的緩存功能($.fn.data)很主要。體積最年夜的 JSON 數據包在頁面 Dom Ready 后進行加載，然后拼裝第一屏的 HTML 代碼并緩存，當用戶按字母索引選擇游戲的時辰再到已加載完的 JSON 數據包中尋找響應的數據去拼裝 HTML 代碼，然后緩存該索引的 HTML 代碼。如不美觀接下來再選擇區、服、生意類型時，再各處事器去取響應的 JSON 數據，拼裝成 HTML 代碼后進行緩存，此時只緩存最后一次的選擇結不美觀。
便平易近中心也同樣是首頁營業邏輯很復雜的模塊，涉及到良多的ajax交互以及表單的操作。各個TAB中的表單是按照請求的JSON數據來生成HTML結構的，原本是每次點擊TAB城市請求一次數據，然后生成HTML結構，每切換一次TAB都要請求，再生成，這真得很二。同樣的數據和結構只要請求一次，并生成一次即可，這種一再的操作是赤裸裸的華侈資本。該模塊的JavaScript原本請求的動態站點的文件，沒有做緩存也沒做過壓縮，每次頁面加載都在這里梗阻一小會。這里的處事端的數據源接口也很亂，開發人員缺乏規范化數據接口的概念。這里的諸多問題，我已無力吐槽了。最后也是年夜頭梳理蛋痛的營業邏輯，重構代碼。
推薦閱讀
跟著搜索引擎算法的不竭進級，我們可以發現算法朝著加倍垂青站內優化的標的目的，事理很簡單無論你的外鏈何等的強年夜，無論你的收錄何等的高量，假如你的站內設置無法知足訪客的需求，不能讓訪客對勁的話，即使優化>>>詳細閱讀
本文標題：<b>網站分析：5173首頁前端性能優化實踐</b>
地址：http://www.brh9h.cn/a/22/20120606/66113.html
網友點評
精彩導讀
科技快報
品牌展示