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