每個參與過開發企業級 web 應用的前端工程師或許都曾思考過前端性能優化方面的問題。我們有雅虎 14 條性能優化原則，還有兩本很經典的性能優化指導書：《高性能網站建設指南》、《高性能網站建設進階指南》。經驗豐富的工程師對于前端性能優化方法耳濡目染，基本都能一一列舉出來。這些性能優化原則大概是在 7 年前提出的，對于 web 性能優化至今都有非常重要的指導意義。

　　然而，對于構建大型 web 應用的團隊來說，要堅持貫徹這些優化原則并不是一件十分容易的事。因為優化原則中很多要求與工程管理相違背，比如“把 css 放在頭部”和“把 js 放在尾部”這兩條原則，我們不能讓整個團隊的工程師在寫樣式和腳本引用的時候都去修改同一份的頁面文件。這會嚴重影響團隊成員間并行開發的效率，尤其是在團隊有版本管理的情況下，每天要花大量的時間進行代碼修改合并，這項成本是難以接受的。因此在前端工程界，總會看到周期性的性能優化工作，辛勤的前端工程師們每到月圓之夜就會傾巢出動根據優化原則做一次最佳實踐。

　　本文從一個全新的視角來思考 web 性能優化與前端工程之間的關系，通過解讀百度前端集成解決方案小組（F.I.S）在打造高性能前端架構并統一百度 40 多條前端產品線的過程中所經歷的技術嘗試，揭示前端性能優化在前端架構及開發工具設計層面的實現思路。

　　性能優化原則及分類

　　筆者先假設本文的讀者是有前端開發經驗的工程師，并對企業級 web 應用開發及性能優化有一定的思考。因此我不會重復介紹雅虎 14 條性能優化原則，如果您沒有這些前續知識的，請移步這里來學習。

　　首先，我們把雅虎 14 條優化原則，《高性能網站建設指南》以及《高性能網站建設進階指南》中提到的優化點做一次梳理，如果按照優化方向分類可以得到這樣一張表格：　　

　　目前大多數前端團隊可以利用 yui compressor 或者 google closure compiler 等壓縮工具很容易做到“精簡 Javascript ”這條原則，同樣的，也可以使用圖片壓縮工具對圖像進行壓縮，實現“圖像優化”原則，這兩條原則是對單個資源的處理，因此不會引起任何工程方面的問題；很多團隊也通過引入代碼校驗流程來確保實現“避免 css 表達式”和“避免重定向”原則；目前絕大多數互聯網公司也已經開啟了服務端的 Gzip 壓縮，并使用 CDN 實現靜態資源的緩存和快速訪問；一些技術實力雄厚的前端團隊甚至研發出了自動 CSS Sprites 工具，解決了 CSS Sprites 在工程維護方面的難題。使用“查找 - 替換”思路，我們似乎也可以很好的實現“劃分主域”原則。

　　我們把以上這些已經成熟應用到實際生產中的優化手段去除掉，留下那些還沒有很好實現的優化原則，再來回顧一下之前的性能優化分類:　　

　　誠然，不可否認現在有很多頂尖的前端團隊可以將上述還剩下的優化原則也都一一解決，但業界大多數團隊都還沒能很好的解決這些問題，因此接下來本文將就這些原則的解決方案做進一步的分析與講解，從而為那些還沒有進入前端工業化開發的團隊提供一些基礎技術建設意見，也借此機會與業界頂尖的前端團隊在工業化工程化方向上交流一下彼此的心得。

　　靜態資源版本更新與緩存

　　如表格 2 所示，在“緩存利用”分類中保留了“添加 Expires 頭”和“配置 ETag ”兩項，或許有些人會質疑，明明這兩項只要配置了服務器的相關選項就可以實現，為什么說它們難以解決呢？確實，開啟這兩項很容易，但開啟了緩存后，我們的項目就開始面臨另一個挑戰：如何更新這些緩存。

　　相信大多數團隊也找到了類似的答案，它和《高性能網站建設指南》關于“添加 Expires 頭”所說的原則一樣——修訂文件名。即：

　　思路沒錯，但要怎么改變鏈接呢？變成什么樣的鏈接才能有效更新緩存，又能最大限度避免那些沒有修改過的文件緩存不失效呢？

　　先來看看現在一般前端團隊的做法：

<script type="text/Javascript" src="a.js?t=20130825"></script>

it知識庫：前端工程與性能優化，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。