阿里巴巴 web前端性能優化進階路

時間 2019-11-12

原文原文鏈接

Web前端性能優化WPO，相信大多數前端同窗都不會陌生，在各自所負責的站點頁面中，也都會或多或少的有過必定的技術實踐。能夠說，這個領域並不缺少成熟技術理論和技術牛人：例如Yahoo的web站點性能優化黃金法則，以及大名鼎鼎的優化大師Steve Souders。本文並不是一篇討論性能優化技術方法的文章，而更多的是對中文站搜索List頁面持續兩年多的前端性能優化實踐的思路總結。但願對正在從事這個領域研究的前端同窗能有所幫助。html

簡單的說，咱們的性能優化實踐分爲三個階段：初探期、立規期、創新期，每一個階段大概持續半年左右，有足夠的時間造成一些優化思路的沉澱。前端

一：初探期

2010年末咱們開始接手搜索List頁面，這是中文站歷史最爲悠久的頁面之一，當時它的生命體徵正如它的年齡同樣，很是虛弱：當時的基調網絡監控顯示，頁面的徹底加載的時間是16秒！做爲以「快」爲核心業務指標的搜索頁面，這個狀態顯然已經是沒法承擔重任了。git

性能是必定要優化的，但咱們也面臨着大多數前端同窗所面臨的共性問題 — 業務需求緊張，何況咱們是剛剛接手這個業務，很是不熟悉，別說是優化了，就是作個小需求也都常常出現線上故障。就是在這樣的狀況下，咱們開始了搜索頁面的性能優化之路，而且給本身定下了當時看起來很是難以實現的目標：在2011年年中前把全頁面加載時間下降到7秒如下。github

咱們很快成立了一個性能優化小組，3-4個前端同窗參與其中，一我的的力量畢竟有限，尤爲是應對這樣一個歷史業務繁多的頁面。參與的同窗多些，技術氛圍也相對濃烈，你們很全面的分解了目前頁面上出現的性能瓶頸，並分別領取了本身的優化任務。web

在這個階段裏，咱們基本是照葫蘆畫瓢，把雅虎性能優化的那些法則與咱們的頁面一一對照，完成了許多優化點，例如：性能優化

小圖片的合併，造成CSS Sprite，並優化圖片
模塊的異步加載
圖片的懶加載
CSS文件引用放在頁面頂部，JS文件引用放在頁面底部，並對代碼壓縮
縮小cookie體積
…

前人的技術理論果真是靠譜，通過咱們半年時間加班加點的性能優化後，咱們奇蹟般的達成了優化目標！（附性能曲線圖）

衆多優化點中，對優化效果貢獻最大的就是對圖片的處理，包括了CSS sprite的合併及圖片的懶加載，說白了就是雅虎性能優化法則的第一條：要儘可能地減小HTTP請求。說實話，CSS sprite合併這塊的體力活較多，但前端同窗必定要引發重視，對頁面性能影響確實很大。

初探期優化經驗所得：

一、優化前，普遍地獲取該領域的各類優化思路。有條件的同窗能夠參加下WPO領域的一些會議，比較推薦 Velocity性能優化大會。

二、成立性能優化組織，明確性能優化目標。

這一點很是重要：可量化的目標以及可持續跟蹤的優化數據是性能優化工做得以持續進行的保障，同時也是源動力！你們能持續這麼長時間迭代的進行優化工做，正是由於每一個階段咱們都有相應的性能優化目標做爲指引，並有志同道合的同窗一塊兒努力。

三、持續追蹤性能數據，要選擇合適的頁面性能測量工具，一旦選定後，再也不更換，以保證歷史數據的可參照性。

咱們一直在使用基調網絡，不得不說仍是很是專業的，不過是收費工具。給自家的測試工具也打個廣告吧，免費的測量工具– 阿里測。國外的測量工具也挺多的，不過受網絡因素影響太大，數據抖動大，不是很推薦使用。

四、性能優化不只僅是能夠直接的提高用戶體驗，對參與其中的前端同窗而言，也是快速熟悉業務的一種捷徑。更進一步說，能夠做爲技術驅動業務的入口，由於優化重構的過程當中你更容易發現歷史業務的不合理之處，從而推進業務方的改造，能夠提高我的的技術影響力。

2、立規期

性能優化工做並不是一朝一夕的事，今天達成了目標，並不意味着明天躺着睡覺也能維持成果。相反，前端性能一般呈現出較高的反覆性，這和新的業務需求有着很是直接的關係，但更底層的緣由一般是咱們並未把性能優化的規範給肯定下來。2011年的下半年，咱們並未在具體性能優化技術點上投入更多的工做，而是作了性能優化的「守道士」，不過這個「守」不是保守的「守」，而是以攻爲守。

一方面咱們制定了針對性能優化前端代碼規範，其中最重要的是對頁面圖片資源的管理規範，歸入到SVN管理，提升新圖片文件添加的成本。

另外一方面咱們創建了「性能聯盟」：性能優化不只僅是前端同窗單方面就可以保證的，更須要產品經理、設計師、Java開發同窗的支持和配合。在這一點上咱們作了不少工做，固然更多的是溝通和意識的影響，讓你們造成一個共識： 性能是最重要的業務功能點！在平時的業務需求中，必定要從性能的角度考慮問題，有理有據的拒絕掉一些有損於前端性能的業務需求。

通過你們的努力，在這個階段，搜索頁面的性能一直維持在７秒鐘左右，長達半年的時間。

立規期優化經驗所得：

一、攻城難，守城更難。制訂優化規範，並嚴格執行，是優化成果得以長期保持的必要保障。前端框架

二、性能優化不是前端同窗本身的事情，須要業務各合做方的共同認同和支持。性能是最重要的業務功能點！cookie

三、前端同窗要加強本身的技術判斷力，正確評估業務需求對性能的影響。同時要提高自身的溝通和影響力。網絡

3、創新期

進入到2012年，隨着咱們對搜索業務理解的逐步深刻，咱們已不知足於在原有前端框架上的修修補補，而是有了更多的自信去完全重寫整個搜索前端應用框架。這也使得性能優化工做進入到一個新的階段。架構

在這個階段，咱們努力的核心目標是：從應用框架和工具的層面作性能優化，讓性能優化成爲一件低成本的事，真正的作到 fast by default！

在搜索應用框架 jEngine的構建過程當中，咱們將一年多的前端優化實踐思路融合在其中，實現了對性能優化友好的模塊註冊機制、BigRender優化模式、<script>標籤無阻塞加載等利用框架便可低成本實現優化的模式的支持。同時jEngine應用框架在模塊化、前端異常監控方面也有着本身獨特的實現，感興趣的同窗能夠研究下。

簡單介紹下對性能友好的模塊註冊機制的實現：jEngine的模塊管理引入了「懶註冊」的機制，全部的頁面模塊被分爲如下三種模塊：

一個模塊的是首屏加載仍是延遲加載，和它自己的類實現沒有關係，只和模塊的註冊方式有關係。

若是他出如今首屏，就使用正常的模塊註冊方式：AppCore.register(「sw_mod_sn」, Searchweb.Business.Category);

若是非首屏模塊，須要頁面滾動加載，或是鼠標事件觸發加載，那麼它的註冊方式只需改爲這樣：

經過這種的方式，能夠低成本的改變頁面初始化過程當中對頁面各模塊的加載方式，從而減小首屏加載的文件個數和JS執行時間。

最後這個階段，咱們不只造成了對性能友好的前端應用框架jEngine，還徹底重寫了搜索各業務模塊代碼，完成了從YUI到jQuery基礎框架的升級，最終把頁面加載時間長期穩定在4秒左右。