[size=small] WPO(Web Performance Optimization , 網站性能優化)近年來發展迅猛,期間YAHOO做出了重要貢獻,YSlow的14條軍規,20條最佳實踐影響深遠.去年Steve出版了第二本書,Velocity大會也從2008開到了2010.各個網站越來越重視速度,也有越來越多開發者投入到WPO大業當中.
在一次内部分享中,整理了Yahoo Rules之外WPO的一些新進展,大雜燴隻是表象,那多是些别人做了的事情.重要的是在目前時期,WPO逐漸進入精耕細作的階段,在放之四海而皆準的Rules被巨頭們提煉的七七八八之後.如何結合自己的應用做最合适的優化?遵循怎樣的思路,借助什麼樣的工具去發現問題,解決問題?從這些新進展中可以看出些端倪,在這裡記錄一下.
[url=http://www.slideshare.net/leneli/after-yahoo-34-rules-5088505]PPT在此,前21頁可以飛速掠過,字型很杯具丫[/url] (>_<)! [/size]
[flash=425,355]http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=ss-100830081009-phpapp02&stripped_title=after-yahoo-34-rules-5088505[/flash]
[size=medium][b]先說思路:[/b][/size]
[size=small] YAHOO将Rules分成Content, Server, Cookie, CSS, JavaScript, Images, Mobile七類是一種思路,讓開發這快速定位到技能相關類别.但是作為前端很可能要同時關注其中N個類别.我們從另一個角度來看,網頁的展現有loading階段和render階段,render階段還是js,css,html三類前端技術,而在loading階段我們則需要關注http:減少http數,優化單個http的各個時間段,減少收發資料量,有效利用緩存等等,如下圖:
[img]http://dl.iteye.com/upload/attachment/303589/4eaca7de-1786-3857-ab9c-87ed3ac06b85.png[/img]
我們要先分析哪個部分慢了,哪裡可能有提升空間,再着手改進.[/size]
[size=medium][b]再說工具:[/b][/size]
[size=small] 借助四類方面的四類工具幫助,更好的覆寫前面優化思路中的各個方面:
[b]一.資料包嗅探工具:[/b]
這類工具關注HTTP的方方面面細節,分析請求間順序和單個http請求各個階段的耗時情況.
典型的如HttpWatch,Firebug的網絡頁簽,Fiddler等等.
另外還有一些全網監控工具可以獲得各個地點監測結果,如基調網絡.
[b]二.運作時分析工具:[/b]
這類工具則更關注運作時JS的性能,各階段記憶體和CPU的使用情況.
典型的如Firebug Profiler, Page Speed Activity一些高階的性能探測工具如Web Page Test, Dynatrace Ajax也都在監控這些方面.
[b]三.記憶體結構分析工具:[/b]
這類的工具還在起步階段,随着複雜Web2.0應用的記憶體洩露風險,随着手持裝置上web app的發展,記憶體使用再次變得重要起來.
主要的IE記憶體洩露的診斷工具Drip, sIEve, JS Memory Leaks Detector.
而在記憶體快照方面Mozilla有其研究,但Chrome先轉化為了實踐.在Chrome自帶的開發者工具中有一個"Profiles"頁簽,其中一項功能"Heap Snapshots"提供記憶體快照,可以從兩個角度觀察記憶體結構,可以多次快照比較差異.在前天的Chrome推介會上,Google的同學也說這個工具還不夠強壯.但是我們仍然可以用好它!回想在firebug之前删代碼+alert是定位問題的不二法門,在記憶體分析工具不夠健壯時,我們隻要多做些test頁,單獨測試我們懷疑的關注的部分就好了.
[b]四.浏覽器内各子系統性能開銷分析工具:[/b]
我們常說"二八"原則,如果浏覽器大量精力耗費在了Dom通路中,而我們卻在優化一個僅2%開銷的算法上,顯然是沒有抓住主要沖突.
在這方面IE一直走在前面,[url=http://blogs.msdn.com/b/ie/archive/2010/08/30/performance-profiling-how-different-web-sites-use-browser-subsystems.aspx]最近的一篇文章剛剛披露了IE各個子系統和若幹網頁展現時各子系統開銷分析[/url],借助這類工具能更好的結合自身應用找到優化關鍵點.[/size]
[size=medium][b]巨頭們精耕細作的實踐案例二則:[/b][/size]
[size=small] [url=http://developer.yahoo.com/performance/rules.html#flush]Flush the Buffer Early[/url]是Yahoo Rules之一.推薦的Flush時機是</head>之後,可以讓浏覽器先行下載下傳<head>中引入的css,js,如下:
[/size]
[size=small] [b]Yahoo[/b]首頁希望能多次flush,首次flush就能展現搜尋框,于是經過測試得出結論:[/size]
[size=small] 經過測試,#page沒有關閉,阻礙了flush内容的提前渲染,是以最新的YUI中布局都去掉了全局的<div>wrapper[/size]
[size=small] [b]Facebook[/b]頁面更複雜,且高度定制化.他們從另一個角度解決這個問題,更加深入的使用flush.[/size]
[size=small] 首先flush出整個頁面布局,然後伺服器端并發請求好友資料,個人資訊,相冊等等子產品,哪一部分先傳回就先将哪一部分作為一個單獨的<script>塊Flush出去,這就是Fackebook近來最主要的優化技術BigPipe,使用這種技術使得Facebook的平均通路速度提高一倍(5s=>2.5s)
從這兩個例子可以看出,YAHOO要搜尋框先看到,于是促成了布局調整,Facebook的頁面HTML内容很多,生成慢,如果使用傳統Ajax會增加過多請求,于是通過Flush促成了動态資訊的combo -- BigPipe,這些都是在Rules基礎上,結合自身網站實際情況發展的很好的優化實踐[/size]
[size=medium][b]淘寶廣告中的優化實踐一則[/b][/size]
[size=small] [url=http://developer.yahoo.com/performance/rules.html#gzip]Gzip Components[/url]也是Yahoo Rules之一,而真正目的是減少收發資料量,那麼在啟用了Gzip之後,進一步提升壓縮效果,也可以更好的達到目标,我們知道壓縮的時候越多重複的内容,壓縮比越高.
廣告json資料中,點選位址是最長的一塊,大概占到一半左右,包含:網站ID,廣告ID,廣告位ID等等字段,經過一定的算法分段hash後輸出.
一次請求傳回多條廣告,我們發現多條廣告之間雖然廣告ID不同,但網站ID,廣告位ID是一樣的,是以我們調整了字段順序,把這些PV級别的資料放在一處,這樣在hash後多條廣告的點選位址當中就多了大段的重複字元串.經過測試,Gzip後的整體輸出資料量降低了三分之一.
可以看出首要理清思路,認準優化目标而不是單純的比對Rules追求YSlow高分.[/size]
[size=medium][b]有關Rules的破與立,不要讓規則束縛腳步[/b][/size]
[size=small] 巨頭們是規則的制定者,但他們卻從不囿于規則當中:
[url=http://developer.yahoo.com/performance/rules.html#js_bottom]Put Scripts at the Bottom[/url] 腳本放在頁面底部,在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頁)
這些也是我反複強調捋順優化思路,認清優化本質的原因:
一.首先認清楚規則帶來的好處.
二.然後不回避規則帶來的問題,如果問題嚴重嘗試解決它,守規則不是借口.
三.如果能獲得更大的好處,我們不妨違反某些規則,以退為進,用實測資料說話.[/size]
[size=medium][b]跟随清晰優化思路解決實際工作中的問題[/b][/size]
[size=small] 最後再介紹兩則在優化思路上的實踐:
[url=http://banner.alimama.com]BannerMaker[/url]是我們使用Flash開發的廣告牌設計和展現工具,沒有使用HTML,CSS,JS,相應的規則就用不上.但思路是同樣的!我們的目标依然是減少初始化負載,減少HTTP請求,充分利用緩存資源,等等.詳見:[url=http://dl.iteye.com/upload/attachment/303695/c4fc11c9-4024-35b2-b83f-5ff2229d0676.png]BannerMaker2010+性能改進路線圖[/url].
我們的有很多營運的同學,進行簡單的HTML類廣告牌制作,在諸多規則中,他們又要重點關注那些?有些技術不是他們專長,但是順着優化的思路就能很好的跟大家解釋為什麼要壓縮甚至合并圖檔,為什麼不要在廣告牌中為了一個效果引入一個類庫.詳見:[url=http://dl.iteye.com/upload/attachment/303697/17fb6c0b-ef22-32a3-8622-1ed608aae99b.png]HTML廣告牌優化(營運版)[/url][/size]
![Yahoo——網站性能優化35條黃金守則[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)