|
|
每個參與過開發(fā)企業(yè)級 web 應(yīng)用的前端工程師或許都曾思考過前端性能優(yōu)化方面的問題。我們有雅虎 14 條性能優(yōu)化原則，還有兩本很經(jīng)典的性能優(yōu)化指導(dǎo)書：《高性能網(wǎng)站建設(shè)指南》、《高性能網(wǎng)站建設(shè)進階指南》。經(jīng)驗豐富的工程師對于前端性能優(yōu)化方法耳濡目染，基本都能一一列舉出來。這些性能優(yōu)化原則大概是在 7 年前提出的，對于 web 性能優(yōu)化至今都有非常重要的指導(dǎo)意義。
然而，對于構(gòu)建大型 web 應(yīng)用的團隊來說，要堅持貫徹這些優(yōu)化原則并不是一件十分容易的事。因為優(yōu)化原則中很多要求與工程管理相違背，比如“把 css 放在頭部”和“把 js 放在尾部”這兩條原則，我們不能讓整個團隊的工程師在寫樣式和腳本引用的時候都去修改同一份的頁面文件。這會嚴(yán)重影響團隊成員間并行開發(fā)的效率，尤其是在團隊有版本管理的情況下，每天要花大量的時間進行代碼修改合并，這項成本是難以接受的。因此在前端工程界，總會看到周期性的性能優(yōu)化工作，辛勤的前端工程師們每到月圓之夜就會傾巢出動根據(jù)優(yōu)化原則做一次最佳實踐。
本文從一個全新的視角來思考 web 性能優(yōu)化與前端工程之間的關(guān)系，通過解讀百度前端集成解決方案小組（F.I.S）在打造高性能前端架構(gòu)并統(tǒng)一百度 40 多條前端產(chǎn)品線的過程中所經(jīng)歷的技術(shù)嘗試，揭示前端性能優(yōu)化在前端架構(gòu)及開發(fā)工具設(shè)計層面的實現(xiàn)思路。
性能優(yōu)化原則及分類
筆者先假設(shè)本文的讀者是有前端開發(fā)經(jīng)驗的工程師，并對企業(yè)級 web 應(yīng)用開發(fā)及性能優(yōu)化有一定的思考。因此我不會重復(fù)介紹雅虎 14 條性能優(yōu)化原則，如果您沒有這些前續(xù)知識的，請移步這里來學(xué)習(xí)。
首先，我們把雅虎 14 條優(yōu)化原則，《高性能網(wǎng)站建設(shè)指南》以及《高性能網(wǎng)站建設(shè)進階指南》中提到的優(yōu)化點做一次梳理，如果按照優(yōu)化方向分類可以得到這樣一張表格：
| 優(yōu)化方向 | 優(yōu)化手段 |
|---|---|
| 請求數(shù)量 | 合并腳本和樣式表，CSS Sprites，拆分初始化負(fù)載，劃分主域 |
| 請求帶寬 | 開啟 GZip，精簡 JavaScript，移除重復(fù)腳本，圖像優(yōu)化 |
| 緩存利用 | 使用 CDN，使用外部 JavaScript 和 CSS，添加 Expires 頭，減少 DNS 查找，配置 ETag，使 AjaX 可緩存 |
| 頁面結(jié)構(gòu) | 將樣式表放在頂部，將腳本放在底部，盡早刷新文檔的輸出 |
| 代碼校驗 | 避免 CSS 表達式，避免重定向 |
目前大多數(shù)前端團隊可以利用 yui compressor 或者 google closure compiler 等壓縮工具很容易做到“精簡 Javascript ”這條原則，同樣的，也可以使用圖片壓縮工具對圖像進行壓縮，實現(xiàn)“圖像優(yōu)化”原則，這兩條原則是對單個資源的處理，因此不會引起任何工程方面的問題；很多團隊也通過引入代碼校驗流程來確保實現(xiàn)“避免 css 表達式”和“避免重定向”原則；目前絕大多數(shù)互聯(lián)網(wǎng)公司也已經(jīng)開啟了服務(wù)端的 Gzip 壓縮，并使用 CDN 實現(xiàn)靜態(tài)資源的緩存和快速訪問；一些技術(shù)實力雄厚的前端團隊甚至研發(fā)出了自動 CSS Sprites 工具，解決了 CSS Sprites 在工程維護方面的難題。使用“查找 - 替換”思路，我們似乎也可以很好的實現(xiàn)“劃分主域”原則。
我們把以上這些已經(jīng)成熟應(yīng)用到實際生產(chǎn)中的優(yōu)化手段去除掉，留下那些還沒有很好實現(xiàn)的優(yōu)化原則，再來回顧一下之前的性能優(yōu)化分類:
| 優(yōu)化方向 | 優(yōu)化手段 |
|---|---|
| 請求數(shù)量 | 合并腳本和樣式表，拆分初始化負(fù)載 |
| 請求帶寬 | 移除重復(fù)腳本 |
| 緩存利用 | 添加 Expires 頭，配置 ETag，使 Ajax 可緩存 |
| 頁面結(jié)構(gòu) | 將樣式表放在頂部，將腳本放在底部，盡早刷新文檔的輸出 |
誠然，不可否認(rèn)現(xiàn)在有很多頂尖的前端團隊可以將上述還剩下的優(yōu)化原則也都一一解決，但業(yè)界大多數(shù)團隊都還沒能很好的解決這些問題，因此接下來本文將就這些原則的解決方案做進一步的分析與講解，從而為那些還沒有進入前端工業(yè)化開發(fā)的團隊提供一些基礎(chǔ)技術(shù)建設(shè)意見，也借此機會與業(yè)界頂尖的前端團隊在工業(yè)化工程化方向上交流一下彼此的心得。
靜態(tài)資源版本更新與緩存
如表格 2 所示，在“緩存利用”分類中保留了“添加 Expires 頭”和“配置 ETag ”兩項，或許有些人會質(zhì)疑，明明這兩項只要配置了服務(wù)器的相關(guān)選項就可以實現(xiàn)，為什么說它們難以解決呢？確實，開啟這兩項很容易，但開啟了緩存后，我們的項目就開始面臨另一個挑戰(zhàn)：如何更新這些緩存。
相信大多數(shù)團隊也找到了類似的答案，它和《高性能網(wǎng)站建設(shè)指南》關(guān)于“添加 Expires 頭”所說的原則一樣——修訂文件名。即：
思路沒錯，但要怎么改變鏈接呢？變成什么樣的鏈接才能有效更新緩存，又能最大限度避免那些沒有修改過的文件緩存不失效呢？
先來看看現(xiàn)在一般前端團隊的做法：
<script type="text/Javascript" src="a.js?t=20130825"></script>
it知識庫：前端工程與性能優(yōu)化，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
