在Yslow 34 Rules之後 -- 網站性能優化思路和進展

http://limu.iteye.com/blog/755628

WPO(Web Performance Optimization , 網站性能優化)近年來發展迅猛,期間YAHOO做出了重要貢獻,YSlow的14條軍規,20條最佳實踐影響深遠.去年Steve出版了第二本書,Velocity大會也從2008開到了2010.各個網站越來越重視速度,也有越來越多開發者投入到WPO大業當中.
        在一次內部分享中,整理了Yahoo Rules之外WPO的一些新進展,大雜燴只是表象,那多是些別人做了的事情.重要的是在當前時期,WPO逐漸進入精耕細作的階段,在放之四海而皆準的Rules被巨頭們提煉的七七八八之後.如何結合自己的應用做最合適的優化?遵循怎樣的思路,藉助什麼樣的工具去發現問題,解決問題?從這些新進展中可以看出些端倪,在這裏記錄一下.

PPT在此,前21頁可以飛速掠過,字體很杯具丫 (>_<)!

先說思路:
        YAHOO將Rules分成Content, Server, Cookie, CSS, JavaScript, Images, Mobile七類是一種思路,讓開發這快速定位到技能相關類別.但是作爲前端很可能要同時關注其中N個類別.我們從另一個角度來看,網頁的展現有loading階段和render階段,render階段還是js,css,html三類前端技術,而在loading階段我們則需要關注http:減少http數,優化單個http的各個時間段,減少收發數據量,有效利用緩存等等,如下圖:

我們要先分析哪個部分慢了,哪裏可能有提升空間,再着手改進.
再說工具:
        藉助四類方面的四類工具幫助,更好的覆蓋前面優化思路中的各個方面:
        一.數據包嗅探工具:
                這類工具關注HTTP的方方面面細節,分析請求間順序和單個http請求各個階段的耗時情況.
                典型的如HttpWatch,Firebug的網絡頁籤,Fiddler等等.
                另外還有一些全網監控工具可以獲得各個地點監測結果,如基調網絡.
        二.運行時分析工具:
                這類工具則更關注運行時JS的性能,各階段內存和CPU的使用情況.
                典型的如Firebug Profiler, Page Speed Activity一些高階的性能探測工具如Web Page Test, Dynatrace Ajax也都在監控這些方面.
        三.內存結構分析工具:
                這類的工具還在起步階段,隨着複雜Web2.0應用的內存泄露風險,隨着手持設備上web app的發展,內存使用再次變得重要起來.
                主要的IE內存泄露的診斷工具Drip, sIEve, JS Memory Leaks Detector.
                而在內存快照方面Mozilla有其研究,但Chrome先轉化爲了實踐.在Chrome自帶的開發者工具中有一個"Profiles"頁籤,其中一項功能"Heap Snapshots"提供內存快照,可以從兩個角度觀察內存結構,可以多次快照比較差異.在前天的Chrome推介會上,Google的同學也說這個工具還不夠強壯.但是我們仍然可以用好它!回想在firebug之前刪代碼+alert是定位問題的不二法門,在內存分析工具不夠健壯時,我們只要多做些test頁,單獨測試我們懷疑的關注的部分就好了.
        四.瀏覽器內各子系統性能開銷分析工具:
                我們常說"二八"原則,如果瀏覽器大量精力耗費在了Dom訪問中,而我們卻在優化一個僅2%開銷的算法上,顯然是沒有抓住主要矛盾.
                在這方面IE一直走在前面,最近的一篇文章剛剛披露了IE各個子系統和若干網頁展現時各子系統開銷分析,藉助這類工具能更好的結合自身應用找到優化關鍵點.
巨頭們精耕細作的實踐案例二則:
        Flush the Buffer Early是Yahoo Rules之一.推薦的Flush時機是</head>之後,可以讓瀏覽器先行下載<head>中引入的css,js,如下:

Php代碼  

... <!-- css, js -->  

</head>  

<?php flush();?>  

<body>  

... <!-- content -->

Yahoo首頁希望能多次flush,首次flush就能展現搜索框,於是經過測試得出結論:

Php代碼  

<body>  

  <div id="page">  

    <div id="search"></div>  

    <?php flush(); ?><!--flush失敗,#search沒有提前渲染-->  

    <div id="main"></div>  

  </div>  

</body>

經過測試,#page沒有關閉,阻礙了flush內容的提前渲染,所以最新的YUI中佈局都去掉了全局的<div>wrapper

Php代碼  

<body>  

  <div id="search"></div>  

  <?php flush(); ?><!--flush成功,#search提前渲染-->  

  <div id="main"></div>  

</body>

Facebook頁面更復雜,且高度定製化.他們從另一個角度解決這個問題,更加深入的使用flush.

Php代碼  

<body>  

  <div id="layout">  

    <div id="mod_profile"></div>  

    <div id="mod_photo"></div>  

    <div id="mod_friend"></div>  

  </div>  

  <?php flush();?><!--首先Flush頁面佈局-->  

  <script>  

    //html string for mod_photo  

  </script>  

  <?php flush();?><!--Flush #mod_photo的內容-->  

  <script>  

    //html string for mod_profile  

  </script>  

  <?php flush();?><!--Flush #mod_profile的內容-->  

  <script>  

    //html string for mod_friend  

  </script>  

</body>

        首先flush出整個頁面佈局,然後服務器端併發請求好友數據,個人信息,相冊等等模塊,哪一部分先返回就先將哪一部分作爲一個單獨的<script>塊Flush出去,這就是Fackebook近來最主要的優化技術BigPipe,使用這種技術使得Facebook的平均訪問速度提高一倍(5s=>2.5s)
        從這兩個例子可以看出,YAHOO要搜索框先看到,於是促成了佈局調整,Facebook的頁面HTML內容很多,生成慢,如果使用傳統Ajax會增加過多請求,於是通過Flush促成了動態信息的combo -- BigPipe,這些都是在Rules基礎上,結合自身網站實際情況發展的很好的優化實踐
淘寶廣告中的優化實踐一則
        Gzip Components也是Yahoo Rules之一,而真正目的是減少收發數據量,那麼在啓用了Gzip之後,進一步提升壓縮效果,也可以更好的達到目標,我們知道壓縮的時候越多重複的內容,壓縮比越高.
        廣告json數據中,點擊地址是最長的一塊,大概佔到一半左右,包含:網站ID,廣告ID,廣告位ID等等字段,經過一定的算法分段hash後輸出.
        一次請求返回多條廣告,我們發現多條廣告之間雖然廣告ID不同,但網站ID,廣告位ID是一樣的,所以我們調整了字段順序,把這些PV級別的數據放在一處,這樣在hash後多條廣告的點擊地址當中就多了大段的重複字符串.經過測試,Gzip後的整體輸出數據量降低了三分之一.
        可以看出首要理清思路,認準優化目標而不是單純的匹配Rules追求YSlow高分.
有關Rules的破與立,不要讓規則束縛腳步
        巨頭們是規則的制定者,但他們卻從不囿於規則當中:
        Put Scripts at the Bottom 腳本放在頁面底部,在DomReady中執行JS是對前端開發影響最深遠的規則之一,而YAHOO,Facebook,MicroSoft卻分別用自己的方法解決JS放在底部帶來的可交互時間被拖後,初始化時間過長等問題(PPT 48頁)
        Douglas Crockford講eval is evil.而Google卻應用eval做JS的增量更新,給出eval在各種瀏覽器中的性能測試,讓Google Map 20-25%的用戶獲得1.25s的速度提升(PPT 37頁)
        Steve Souders講要儘量不要使用iframe,而最近卻在twitter中爲meboo推介的名爲iframed js的跨域無阻塞異步腳本下載方案拍手稱快(PPT 49頁)
        這些也是我反覆強調捋順優化思路,認清優化本質的原因:
        一.首先認清楚規則帶來的好處.
        二.然後不迴避規則帶來的問題,如果問題嚴重嘗試解決它,守規則不是藉口.
        三.如果能獲得更大的好處,我們不妨違反某些規則,以退爲進,用實測數據說話.
跟隨清晰優化思路解決實際工作中的問題
        最後再介紹兩則在優化思路上的實踐:
        BannerMaker是我們使用Flash開發的廣告牌設計和展現工具,沒有使用HTML,CSS,JS,相應的規則就用不上.但思路是同樣的!我們的目標依然是減少初始化負載,減少HTTP請求,充分利用緩存資源,等等.詳見:BannerMaker2010+性能改進路線圖.
       我們的有很多運營的同學,進行簡單的HTML類廣告牌製作,在諸多規則中,他們又要重點關注那些?有些技術不是他們專長,但是順着優化的思路就能很好的跟大家解釋爲什麼要壓縮甚至合併圖片,爲什麼不要在廣告牌中爲了一個效果引入一個類庫.詳見:HTML廣告牌優化(運營版)