網(wǎng)站性能優(yōu)化最佳實(shí)踐
原創(chuàng)【51CTO 7月6日外電】近幾年來(lái)，Web應(yīng)用程序的性能變得越來(lái)越重要，甚至比業(yè)務(wù)還重要，因?yàn)樗阉饕妫ㄈ鏕oogle）在排名時(shí)，會(huì)將網(wǎng)站的性能因素納入考慮，最終形成了“性能==更好的可見性==更多的用戶==更多的收入”這樣的連環(huán)效應(yīng)。
51CTO推薦閱讀：創(chuàng)建大型高性能Web站點(diǎn)的十項(xiàng)規(guī)則
網(wǎng)站性能測(cè)試的最佳辦法是看幾個(gè)能告訴你網(wǎng)站快慢的KPI（Key Performance Indicators，關(guān)鍵性能指標(biāo)），這些指標(biāo)由Web性能專家（如Steve Souders）和公司（如Google，Yahoo）推動(dòng)的，其中頁(yè)面載入時(shí)間，網(wǎng)絡(luò)往返次數(shù)，傳輸內(nèi)容的大小是衡量一個(gè)Web頁(yè)面性能的重要指標(biāo)，同時(shí)51CTO也曾報(bào)導(dǎo)過(guò)《Google專家：JavaScript是網(wǎng)站性能的致命克星》。dynaTrace AJAX版本擴(kuò)展了現(xiàn)有KPI列表，包括可測(cè)量首次顯示時(shí)間，完全載入時(shí)間，JavaScript執(zhí)行時(shí)間等。
載入時(shí)間方面的KPI
從最終用戶性能的角度來(lái)看，訪問(wèn)一個(gè)網(wǎng)站會(huì)經(jīng)歷3個(gè)有趣的階段，dynaTrace AJAX版本在TimeLine視圖中可視化展示了頁(yè)面載入的不同階段，這里我突出顯示了首次顯示時(shí)間，onLoad時(shí)間和完全載入時(shí)間，如下圖所示。
圖1 訪問(wèn)一個(gè)網(wǎng)頁(yè)的整個(gè)過(guò)程
1、首次顯示時(shí)間
這個(gè)時(shí)間等于在瀏覽器地址欄輸入U(xiǎn)RL按回車到用戶看到網(wǎng)頁(yè)的第一個(gè)視覺標(biāo)志為止，第一個(gè)視覺標(biāo)志是瀏覽器的第一個(gè)繪制活動(dòng)，瀏覽器繪制內(nèi)容的起始時(shí)間取決于原始的HTML文檔，不同的策略有不同的最佳實(shí)踐，例如Google會(huì)先下載一個(gè)極簡(jiǎn)的頁(yè)面提供快速的第一視覺呈現(xiàn)，在onLoad后再延遲加載更多的內(nèi)容，有時(shí)甚至是用戶已經(jīng)開始與網(wǎng)頁(yè)交互了才加載剩下的內(nèi)容。
2、onLoad事件時(shí)間
這個(gè)時(shí)間是直到瀏覽器觸發(fā)onLoad事件的時(shí)間，當(dāng)原始文檔和所有引用的內(nèi)容完全下載后才會(huì)觸發(fā)這個(gè)事件，JavaScript onLoad處理程序使用這個(gè)事件操作頁(yè)面的當(dāng)前初始狀態(tài)。
3、完全載入的時(shí)間
這個(gè)時(shí)間等于直到所有onLoad JavaScript處理程序執(zhí)行完畢，所有動(dòng)態(tài)的或延遲加載的內(nèi)容都通過(guò)這些處理程序觸發(fā)的時(shí)間，有時(shí)要精確確定一個(gè)頁(yè)面的完全載入時(shí)間是很困難的，特別是當(dāng)JavaScript處理程序使用了不斷修改頁(yè)面的操作時(shí)，如實(shí)時(shí)股票顯示。
#p#
資源方面的KPI
一個(gè)網(wǎng)頁(yè)是由原始的HTML文檔，嵌入的資源，如圖片，css，JavaScript腳本和通過(guò)VHR或JavaScript修改DOM動(dòng)態(tài)下載的內(nèi)容，網(wǎng)頁(yè)上引用的資源越多，在瀏覽器和服務(wù)器之間因下載資源往返的次數(shù)就越多，資源尺寸越大，就需要更多的帶寬傳輸，減少往返次數(shù)和資源尺寸很重要，dynaTrace AJAX版本提供了一個(gè)網(wǎng)絡(luò)視圖，可對(duì)每個(gè)獨(dú)立的資源進(jìn)行分析，如下圖所示。
圖2 網(wǎng)頁(yè)引用的各個(gè)資源消耗的時(shí)間
從這個(gè)網(wǎng)絡(luò)視圖我們可以看到多個(gè)網(wǎng)絡(luò)資源相關(guān)的KPI，有助于我們理解頁(yè)面的結(jié)構(gòu)和尺寸。
1、總請(qǐng)求數(shù)
這是從網(wǎng)站下載資源時(shí)所有網(wǎng)絡(luò)請(qǐng)求的總數(shù)，終極目標(biāo)是使這個(gè)數(shù)量盡可能的低，以便減少往返次數(shù)。
2、HTTP 300s/HTTP 400s/HTTP 500s的總數(shù)
它們分別是服務(wù)器用HTTP狀態(tài)碼300（重定向）/400（授權(quán)問(wèn)題）和500（服務(wù)器錯(cuò)誤）響應(yīng)HTTP請(qǐng)求的總數(shù)，應(yīng)該盡量避免這些請(qǐng)求，因?yàn)樗鼈儗?duì)頁(yè)面載入時(shí)間有負(fù)面影響，這些問(wèn)題的根本原因通常與服務(wù)器端的實(shí)現(xiàn)，配置和部署有關(guān)。
3、網(wǎng)頁(yè)的總大小
這是組成你網(wǎng)頁(yè)的所有資源總大小，跟蹤總的頁(yè)面大小非常重要，網(wǎng)頁(yè)越大下載的時(shí)間就越長(zhǎng)，向網(wǎng)頁(yè)添加圖片或JavaScript代碼都會(huì)影響網(wǎng)頁(yè)的下載時(shí)間，相反，盡可能做到每個(gè)網(wǎng)頁(yè)包含的資源總大小較小會(huì)加快網(wǎng)頁(yè)在瀏覽器中的顯示。
4、圖像/CSS/JS總大小
除了跟蹤網(wǎng)頁(yè)的總大小外，調(diào)查每個(gè)獨(dú)立內(nèi)容類型，如圖像，CSS和JavaScript文件的大小也很重要，這樣就可以很容易辨認(rèn)頁(yè)面中哪一個(gè)內(nèi)容的尺寸最大，我們應(yīng)該避免使用較大尺寸的文件，如圖片文件應(yīng)使用專業(yè)優(yōu)化工具進(jìn)行優(yōu)化，JavaScript和css文件則可以通過(guò)Web服務(wù)器進(jìn)行壓縮后向客戶端傳輸。
5、XHR請(qǐng)求總數(shù)
通過(guò)JavaScript發(fā)送的XmlHttpRequests（XHR）請(qǐng)求總數(shù)，它從服務(wù)器異步檢索數(shù)據(jù)，監(jiān)視這個(gè)KPI可以找出通過(guò)XHR動(dòng)態(tài)內(nèi)容檢索時(shí)發(fā)生的意外變化，根據(jù)配置，你可以終結(jié)那些不僅影響客戶端性能，也會(huì)導(dǎo)致應(yīng)用程序服務(wù)器負(fù)載過(guò)多的XHR請(qǐng)求。
#p#
網(wǎng)絡(luò)連接方面的KPI
瀏覽器底層網(wǎng)絡(luò)連接也是影響網(wǎng)站內(nèi)容下載速度的主要因素，下載內(nèi)容的過(guò)程分幾個(gè)階段，dynaTrace AJAX版本可以顯示每個(gè)網(wǎng)絡(luò)請(qǐng)求的所有階段，如下圖所示。
圖3 網(wǎng)絡(luò)連接的幾個(gè)階段
瀏覽器處理請(qǐng)求的過(guò)程分為幾個(gè)階段，下面就對(duì)這些階段的影響加以解釋。
1、DNS時(shí)間
托管網(wǎng)站資源的每個(gè)域名都會(huì)發(fā)生一次DNS查找，如果你在多個(gè)網(wǎng)頁(yè)之間移動(dòng)，當(dāng)前一個(gè)頁(yè)面已經(jīng)請(qǐng)求過(guò)一次DNS查找后，瀏覽器不會(huì)再對(duì)同一個(gè)域名請(qǐng)求另一個(gè)DNS查找，但通過(guò)查看總體DNS時(shí)間，可以確定是否存在DNS查找時(shí)間問(wèn)題，有可能牽出DNS配置不當(dāng)?shù)膯?wèn)題。
2、連接時(shí)間
根據(jù)瀏覽器和資源的大小不同，瀏覽器可能會(huì)在域名上建立一到多個(gè)連接，連接時(shí)間就是瀏覽器與Web服務(wù)器建立TCP/IP連接的時(shí)間，連接通常會(huì)保持打開狀態(tài)，除非Web服務(wù)器命令瀏覽器關(guān)閉連接。當(dāng)使用SSL建立安全通信時(shí)，連接時(shí)間也包括SSL握手的時(shí)間，連接時(shí)間過(guò)長(zhǎng)有以下原因：到Web服務(wù)器的網(wǎng)絡(luò)連接速度較慢，使用了SSL，不允許瀏覽器保持連接打開。
3、服務(wù)器時(shí)間
高服務(wù)器時(shí)間意味著Web/應(yīng)用程序服務(wù)器需要很長(zhǎng)的時(shí)間處理請(qǐng)求，監(jiān)視服務(wù)器時(shí)間對(duì)于找出性能瓶頸和應(yīng)用程序的擴(kuò)展問(wèn)題是至關(guān)重要的，通過(guò)增加Web服務(wù)器實(shí)現(xiàn)負(fù)載均衡，使靜態(tài)內(nèi)容的擴(kuò)展是很容易的，當(dāng)然也可以購(gòu)買CDN加速服務(wù)來(lái)達(dá)到同樣的目的，但以這種方法實(shí)現(xiàn)動(dòng)態(tài)應(yīng)用程序擴(kuò)展就行不通了。
4、傳輸時(shí)間
這個(gè)時(shí)間與傳輸內(nèi)容的大小，瀏覽器與服務(wù)器之間的連接速度緊密相關(guān)，保持低傳輸時(shí)間是確保頁(yè)面快速載入的關(guān)鍵，可以通過(guò)減小總的頁(yè)面大小，或者通過(guò)CDN將內(nèi)容放在離最終用戶較近的地方改善傳輸時(shí)間。
5、等待時(shí)間
等待時(shí)間與相同域名下資源的數(shù)量直接相關(guān)，受瀏覽器同一域名物理網(wǎng)絡(luò)連接數(shù)的限制，訪問(wèn)某個(gè)資源時(shí)可能必須等待另一個(gè)連接的釋放，減少資源的數(shù)量，或?qū)①Y源分布在多個(gè)域名上，可以有效減少等待時(shí)間。
6、域名的數(shù)量
托管網(wǎng)站資源域名的數(shù)量也很重要，因?yàn)樗鼤?huì)影響DNS，連接和等待時(shí)間，要下載的資源使用額外的域名將會(huì)直接減少等待時(shí)間，因?yàn)闉g覽器最終使用更多的物理連接，但如果需要非常多的DNS查找時(shí)，這又會(huì)產(chǎn)生負(fù)面影響，此外，應(yīng)該盡量避開單一資源域名，但有時(shí)是無(wú)法避免的，如從外部?jī)?nèi)容提供商下載資源時(shí)（如廣告服務(wù)）。
#p#
性能改善建議和排名計(jì)算
網(wǎng)站的終極目標(biāo)是盡可能塊地載入內(nèi)容，實(shí)現(xiàn)這個(gè)目標(biāo)的辦法有很多，如減少網(wǎng)絡(luò)往返次數(shù)，使用緩存，優(yōu)化服務(wù)器端內(nèi)容生成，優(yōu)化JavaScript/Ajax等，在這四個(gè)領(lǐng)域進(jìn)行優(yōu)化，以及延遲載入JavaScript代碼，js和css文件，都將會(huì)改善頁(yè)面的載入時(shí)間。dynaTrace AJAX版本可以根據(jù)我們本文討論的某些KPI計(jì)算頁(yè)面排名，我們使用下面的閥值來(lái)定義優(yōu)秀，可接受和糟糕的頁(yè)面速度。（相關(guān)文章推薦：實(shí)戰(zhàn)Web2.0網(wǎng)站性能調(diào)優(yōu)）
◆首次顯示的時(shí)間如果<1s，則優(yōu)秀，如果<2.5s則是可接受的，如果>2.5s則很慢；
◆onLoad時(shí)間如果<2s，則優(yōu)秀，如果<4s則是可接受的，如果>4s則很慢；
◆完全載入時(shí)間如果<2s，則優(yōu)秀，如果<5s則是可接受的，如果>5s則很慢。
最重要的因素是首次顯示時(shí)間，其次是onLoad時(shí)間，然后是完全載入時(shí)間。我們也將HTTP請(qǐng)求的數(shù)量作為一個(gè)重要因素看待，因?yàn)橥档拇螖?shù)對(duì)總的下載時(shí)間影響甚大，優(yōu)秀的網(wǎng)站請(qǐng)求數(shù)應(yīng)小于40，可接受的網(wǎng)站請(qǐng)求數(shù)最大不能超過(guò)100，超過(guò)100的網(wǎng)站可認(rèn)為是糟糕的。
dynaTrace AJAX也可以計(jì)算瀏覽器緩存，網(wǎng)絡(luò)資源，JavaScript/Ajax和服務(wù)器端活動(dòng)的排名，總的排名是每個(gè)子排名分別加權(quán)10%計(jì)算出來(lái)的，因此總排名等于KPI排名結(jié)果*60%加上緩存，網(wǎng)絡(luò)，JavaScript和服務(wù)器端活動(dòng)排名計(jì)算結(jié)果的10%得出的。
原文名：Best Practices on Web Site Performance Optimization
原文出處：https://community.dynatrace.com/community/display/PUB/Best+Practices+on+Web+Site+Performance+Optimization
【51CTO.com譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處。】
【編輯推薦】
