愛悠閑 > Web性能優化寶典

Web性能優化寶典

標簽: Web性能優化寶典  |  作者: cse1314 相關  |  發布日期 : 2014-05-04  |  熱度 : 149°

Web性能優化寶典

緒論

性能優化一直是系統開發和項目維護中經久不衰的話題,性能問題也往往是程序員們談虎色變的詬病。隨著互聯網的高速發展,越來越多的應用系統已經以web的形式擺上了臺面。而在Web系統中,性能問題絕大部分體現為頁面的快速響應和系統的持續穩定。根據yahoo的調查,后臺只占5%,而前端高達95%之多,其中有88%的東西是可以優化的。

虛話不多說,就以業界的2-5-8原則來拉開本次Web性能優化話題的篇章吧。

當用戶能夠在2秒以內得到響應時,會感覺系統的響應很快,用戶體驗非常好

當用戶在2-5之間得到響應時,會感覺系統的響應速度還可以

當用戶在5-8以內得到響應時,會感覺系統的響應速度很慢,勉強可以使用

當用戶在超過8后仍然無法得到響應時,會感覺系統糟透了,或者認為系統已經失去響應,而選擇離開這個Web站點

 

 

 

 

 

 

 

1 兵法篇

凡用兵之道,以法為首。有法可依者,制勝之方也。

 

內容(Content)方面

1)盡量減少HTTP請求次數

    終端用戶響應的時間中,大部分是在下載各項內容。這部分時間包括下載頁面中的圖像、樣式表、腳本、Flash等。通過減少頁面中的元素可以減少HTTP請求的次數。

減少HTTP請求的方式通常有:

1.合并文件。通過把所有的腳本放到一個文件中來減少HTTP請求的方法,如可以簡單地把所有的CSS文件都放入一個樣式表中。

2.CSS Sprites。減少圖像請求的有效方法。把所有的背景圖像都放到一個圖片文件中,然后通過CSS的background-image和background-position屬性來顯示圖片的不同部分;

 

2)減少DOM元素數量

關注以下原則:

1. 一個復雜的頁面意味著需要下載更多數據,同時也意味著JavaScript遍歷DOM的效率越慢。

2. 只有在語意上有意義時才使用<div>,而不是因為它具有換行效果才使用它。

3. 一個頁面的Dom應盡量控制在500個之內,計算Dom元素個數的方法可以通過document.getElementsByTagName('*').length獲得。

 

3)使iframe的數量最小

Iframe讓頁面無縫集成的特性使之在Web系統中大受青睞,但同時我們也要看到iframe的缺點,不能濫用iframe:

1. 即時內容為空,加載也需要時間。

2. 會阻止頁面加載。

3. 沒有語意的iframe請使用div代替,完全可以實現同樣的效果。

4. 對客戶端的負荷相對較重。

 

4)減少DNS查詢   

一次DNS的解析過程會消耗20-120毫秒的時間,在dns查詢結束之前,瀏覽器不會下載該域名下的任何東西。所以減少dns查詢的時間可以加快頁面的加載速度。建議一個頁面所包含的域名數盡量控制在2-4個。

 

5)不要出現404錯誤   

HTTP請求時間消耗是很大的,因此使用HTTP請求來獲得一個沒有用處的響應(例如404沒有找到頁面)是完全沒有必要的,它只會降低用戶體驗而不會有一點好處。

 

 

服務端(server)方面

1)采用緩存機制

緩存機制指的是促使客戶端在訪問系統時,盡量采用本地緩存文件,避免與服務端進行重復的交互。這種方式能夠最大程度的減輕服務端和網絡的負荷,有效提高頁面性能。

httpResponse.addHeader("Cache-Control","private,max-age=86400");//緩存一天

需要注意的是,通常緩存僅針對靜態資源而言,如圖片,XML,JS,CSS等。對于動態數據是不能采取緩存的。因此在服務端做緩存時,需要根據后綴名做區分。

<filter-mapping>

  <filter-name>staticResouceCacheFilter</filter-name>

  <url-pattern>*.gif</url-pattern>

 </filter-mapping>

 <filter-mapping>

 <filter-name>staticResouceCacheFilter</filter-name>

  <url-pattern>*.png</url-pattern>

 </filter-mapping>

 <filter-mapping>

  <filter-name>staticResouceCacheFilter</filter-name>

  <url-pattern>*.js</url-pattern>

 </filter-mapping>

 <filter-mapping>

 <filter-name>staticResouceCacheFilter</filter-name>

  <url-pattern>*.css</url-pattern>

 </filter-mapping>

 <filter-mapping>

  <filter-name>staticResouceCacheFilter</filter-name>

  <url-pattern>*.html</url-pattern>

 </filter-mapping>

 

2)采用GZip壓縮

Gzip是指把文件先在服務器端進行壓縮,然后再傳輸。這樣可以顯著減少文件傳輸的大小。傳輸完畢后瀏覽器會重新對壓縮過的內容進行解壓縮,并執行。gzip的壓縮比例非常大,一般壓縮率為85%,服務器端100K的頁面可以壓縮到25K左右再發送到客戶端。特別強調, 所有的文本內容都應該被gzip壓縮: html (php), js, css, xml, txt…

方法為,在容器的配置文件中,對http端口的配置加入如下:

<Connector port="5050"address="${jboss.bind.address}"

  maxThreads="300"strategy="ms" maxHttpHeaderSize="8192"

 emptySessionPath="false" enableLookups="false"redirectPort="5000"

  acceptCount="100"connectionTimeout="15000" maxSpareThreads="75"

  minSpareThreads="10"disableUploadTimeout="true" URIEncoding="UTF-8"

  compression="on"

  compressionMinSize="2048"

  noCompressionUserAgents="gozilla,traviata"

  compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain,application/json"/>

 

 

靜態資源(JavaScript ,CSS,Image方面

1)壓縮 JavaScript,CSS和Image

原因不必多贅述,另外一個角度的避免因網絡情況差而出現的性能瓶頸。

 

2)正確使用和放置js和css 

請關注以下原則:

1. 將CSS樣式放在頁面的head區域,避免頁面在加載過程中出現空白或無樣式。

2. 將外聯JS放在頁面的head區域,避免加載不到JS的情況出現。

3. 將執行的JS放到頁面的最下方,避免瀏覽器在解釋JS時,發生阻塞而導致頁面加載停滯。

4. 避免使用 CSS 中的 Expressions。

 

3)將 JavaScript 和 CSS 獨立成外部文件 

覺得這一點和內容部分的“盡量減少HTTP請求數量”貌似有點沖突?其實不然。

先關注一下IE作為的HttpClient的并發能力:

IE6:1個并發

IE7:2個并發

IE8:默認6個并發且可以自行設置。

可以看到,在高版本IE的支持并發,且在網絡情況良好的情況下,采用多個外聯文件的方式加載js和css,可以最大程度的利用客戶端和網絡的資源,快速訪問頁面。

 

4)移除重復的腳本 

這點不說也知道,不僅是從性能上考慮,代碼規范上看也是這樣。不得不承認,很多時候我們會因為圖一時之快而加上一些或許是重復的代碼。采用一個統一的css框架和js框架可以比較好的解決這個問題。如,JQuery。

2 兵練篇

學而不用,紙上談兵,是以為殆也。

 

以下借鑒在MDSP中做性能優化或性能攻關中各個案例,為大家講述各式各樣的性能問題的定位思路和解決之道。

 

網絡不暢導致網絡傳輸超慢,前后臺交互耗時長,用戶體驗極其低下。(江蘇移動)

問題現象:MDMC所有頁面訪問速度極其慢。

定位思路:

1.所有頁面訪問速度都慢,說明不是單頁面問題而是統一性問題。如:后臺CPU居高不下或內存占用異常,導致MDMC無法處理頁面請求;或者是網絡帶寬問題;或者是MDMC的過濾器問題。

2.通過top命令發現后臺資源無異常。(排除后臺資源問題)

3.搭建簡單tomcat環境+靜態頁面,訪問速度仍然慢。(排除MDMC系統過濾器問題)

4.通過客戶端ping命令發現網絡丟包嚴重。(初步找到原因)

5.通過httpWatch(參考兵器篇的詳細介紹)監控,發現每個http請求的時間都耗在wait階段(進一步證實網絡故障):

6.關閉服務端和客戶端的防火墻,訪問速度仍然慢。(排除防火墻帶來的網絡傳輸問題,最終確認問題根因為:網絡本身的連通性問題

解決方案:

1.由于局方堅持保持網絡現狀,只能從系統方面優化。

2.根據兵法篇做服務端優化,首先采用靜態資源緩存,效果相當明顯。頁面在使用本地緩存文件之后,訪問頁面的速度得到極大提升。

3.進一步采用Gzip壓縮,則即使是第一次訪問系統,速度也較優化前提升50%。

 

        DOM元素過多導致頁面瀏覽的響應時間極長,用戶體驗極其低下。(游戲基地/越南VMS)

問題現象:MDMC的呈現詳情頁面訪問速度極長。

定位思路:

1.其他頁面訪問均正常,說明是單頁面問題。

2.通過IE Developer(詳細介紹參見兵器篇)逐個查看頁面元素,發現有2000多個<input type=”checkbox”>的dom元素。

3.查看相關頁面代碼,搜索checkbox,發現如下js:

for (var i=0;i<checkboxes.length;i++){….}

得知該for循環將執行2000次,每次都會操作DOM元素進行頁面的重繪和渲染。

4.確認問題根因為:DOM元素過多導致頁面解析和渲染時間超長

解決方案:

1.分析:checkbox的數量為何如此之多?(現網終端數目多,2000多款)

2.討論:由于是瀏覽頁面(只讀),只需要展示選中終端即可,無需展示所有終端。

3.實施:將瀏覽頁面改為僅展示選中終端。

問題解決。

 

文件控件元素過多,且沒有清空,導致表單提交數據超大,表單提交失敗,阻塞內容發布及后續流程。(動漫基地)

問題現象:MDMC的新增實體文件頁面上,當實體文件到達一定數目時,提交失敗表單失敗,阻塞內容發布流程。

定位思路:

1.查看后臺日志,發現報File size exceed。

2.查看配置文件,發現文件上傳上限為2M。

3.使用httpWatch(詳細介紹參見兵器篇)查看頁面表單提交數據(send),總大小有3M之多。(異常現像)

4.使用IE Developer(詳細介紹參見兵器篇)查看頁面中有10個左右的input type=file,并且value不為空。(找到問題)

5.確認問題根因為:表單中文件控件過多,表單提交時數據超大

解決方案:

1.文件提交動作和表單提交動作不需要同時執行,否則可能會數據超大。

2.將文件提交改為動態生成input type=file的方式,并在提交成功后,remove掉input,避免頁面產生冗余的DOM。

問題解決。

 

列表頁面迭代設計不合理導致頁面響應時間極長,用戶體驗低下。(動漫基地)

問題現象:MDMC的內容列表頁面響應時間極長。

定位思路:

1. 使用httpWatch(詳細介紹參見兵器篇)查看列表頁面,發現每次訪問列表頁面,http請求action有11次之多。(異常現像)

2. 將列表改成每頁50條,再次訪問列表頁面,發現http請求action有51次之多.。(次數跟分頁數目有關)

3. 查看列表頁面代碼,發現列表在每次迭代時,會發起一個http請求。(確定問題)

4.確認問題根因為:列表頁面迭代涉及不合理,導致http請求次數過多

解決方案:

1.分析:為什么要在頁面迭代中再次請求?(額外的列表項需求)

2.實施:即使是額外的列表項需要展示,也應該在后臺一次性獲取到,并封裝到列表數據對象中。

問題解決。

 

3 兵器篇

工欲善其事,必先利其器。

 

前臺分析工具

1)HttpWatch Professional 

HttpWatch Professional絕對是Web性能定位分析工具的首選。該工具簡單易用,并能輕量集成到IE中,實時監控http請求中從始到終的各種數據和狀態。其中的URL瀑布圖,TimeChart,發送數據(頭),響應數據(頭),是我們定位Web問題(不僅僅是性能問題)的最常用手段。另外,其Cookie,Cache等數據,更是一些Web疑難雜癥的線索藏身之處。可謂是“Watch在手,數據全有”。該工具也是作者使用最頻繁的武器(沒有之一)。強烈推薦Web開發人員必備,人手一份。詳細使用方法,請見附件中的說明。

 

 

2)IE Developer ToolBar

IE Developer ToolBar其實是一款頁面Dom分析工具,它能夠以樹狀菜單的形式描述一個完整的頁面Dom結構,相應的勾勒出頁面控件的形狀,并能夠顯示每個Dom的js或css屬性,便于開發人員直觀的分析和定位。

 

3)FireBug 

      FireBug其實是FireFox的自帶插件,其功能跟HttpWatch相差無幾,只是所依附的瀏覽器不同。(HttpWatch也有FireFox版的插件)

 

4)Page Speed

      Page speed 是基于Firebug的1個工具,主要可以對頁面進行評分,總分100分,而且會顯示對各項的改進意見,Page Speed也能檢測到JS的解析時間。

      對于開發人員而言,這款工具的神奇之處就是在于它能通過自動評分的方式,評價頁面各項指標的好壞,讓開發人員能夠聚焦于正確的優化方向,大大減少自行分析和定位的時間,可以稱得上是Web系統性能優化的進階利器。

5)DynaTrace's Ajax Edition

      Web系統性能分析終極工具,Web頁面的各種缺陷可以通過該工具一覽無余。不但可以檢測資源加載瀑布圖,而且還能監控頁面呈現時間,頁面渲染過程,網絡傳輸性能,客戶端CPU開銷,JS分析和執行時間,CSS解析時間等等。同時,它也能像PageSpeed一樣給出頁面各項指標的評分。熟練掌握該工具,可以精確定位Web系統的各類性能問題。附件是該工具的使用指南。

后臺分析工具

1)線程和堆棧分析工具(IBM Thread and Monitor)

分析jave core文件,常用于查看阻塞線程以及分析堆棧。

2)heapdump分析工具(IBM HeapAnalyzer)

      分析java heap文件。用于查看heapdump中的java對象的占用情況,判斷java大對象的GC狀態。

這個工具的意義非常重大,大家都知道在java自帶gz的機制,并且沒有sizeOf及類似的方法用于計算對象大小,因此在定位java一些大對象帶來的性能問題時,往往比較吃力。該工具能夠以樹形菜單和對象列表的形式將dump文件中的java對象詳細展示出來,包括size, total, type等等,非常直觀。

以下是該工具的使用指南。

 

 

 

 

 

 

 

 

 

 

 

 

后記

性能問題永遠都不會有一個最終的完美方案。其要點在于,設計,編程,配置,測試時要有性能的概念。思考自己的每一個動作會對性能造成什么樣的影響。性能的改進依賴于測試,任何改進都必須有性能測試報告來證明其是行之有效的,而不是拍腦袋拍出來的。性能的改進同時依賴于團隊對于性能持久的關注,而不是有了問題才想到去解決。

希望該文檔對能夠讓大家對性能優化問題有初步的接觸和了解,認識到性能問題并不可怕,只要能夠找對方向,抓住要點,實施行之有效的改進,任何性能問題都是紙老虎。

 



快乐彩中奖说明