● 服務器花在處理客戶請求上的時間。
● 網絡花在傳輸請求和響應上的時間
● 客戶花在組裝并顯示結果內容上的時間。
當然，實際情形遠比這要復雜，原因下面分別進行介紹。
服務發現
開始訪問任何網站時，客戶都需要先找到服務器。通常這是由DNS查詢完成的，盡管客戶可能已經緩存了服務器的IP地址。有時候可能需要多走幾步才能找到正確的服務器，像HTTP重定向這種操作，就會把客戶引向另外的地方。
什么時候客戶需要從新的服務器獲取內容，都要經歷這種服務發現過程。結果，對于帶有很多組件的網站一這是一個日漸普遍的模式一一都會迫使客戶去解析很多網站，并且頁面的加載時間也延長了。
現代的網站都依賴于第三方組件提供諸如支付、嵌入式視頻、到社會媒體的鏈接、監控等的功能。然而，每個附加組件都是一個令人擔心的失效點，并且也是導致頁面加載延遲的罪魁，硬生生地剝奪了高效網站的優勢。
發送請求
網絡再快，客戶與服務器之間的往返也是需要時間的，部分原因是物理學上的限制:光從紐約到拉斯維加斯需要13毫秒，那么數據從紐約到拉斯維加斯就不可能比13毫秒更快從瀏覽器到內容之間的網絡速度是導致延遲的首要因素。
Web請求可能會很簡單: GET index.html，然而，更為常見的卻是很復雜的請求，包括cookies、URI參數，甚至還有 POSTS上載內容的操作。請求包含的內容越多，則網絡用來傳輸的時間就越長。假如是一個安全頁面的話，還會有另外的延遲，用來在客戶與服務器之間進行加密協商。
再考慮響應
請求到達服務器的以后，另一個導致延遲的罪魁就登場了:主機。不論是從內存中檢索靜態對象，還是利用后臺的第三方服務來完成一個復雜的請求，主機延遲都會對性能造成影響。關于后臺服務造成的延遲，本書其他章節有討論，這里就不多說了。主機延遲是造成糟糕用戶體驗的主要原因，所以，除了在后臺對其進行測量之外，在網站之外對其進行追蹤也是非常重要的。
記住，假如網站依賴于第三方組件，則也要對這些外部網站的主機延遲進行測量，而且還可以針對這些提供商起草一份服務水平協議(SLAs)，確保他們的網站能夠滿足你的延遲標準。
發送響應
響應內容一旦準備就緒，服務器就可以通過HTTP協議發送這些請求對象，正是這些對對象的發送造成了訪客體驗到的延遲。
雖然看起來似乎是帶寬一一給定時段內客戶與服務器之間傳送的數據量一一對頁面延遲負有責任，事實上，頁面中的對象數量以及這些對象從何而來，通常決定著頁面加載所花費的時間。
Web頁面極少只包含一個對象，對于大多數頁面，容器對象(page. html)包含有對組件對象( Image.gif、 video.mo、audio.Wav、movie.Swf)的引引用，從而，這些對象也要抽取過來。而瀏覽器對于在同時能夠檢索多少對象上也是有限制的。所以，頁面加載所用時間，是對象數量、對象大小、同時能夠檢索的對象數量、可用帶寬的綜合作用。
異步通信與刷新
某些應用包括一些客戶與服務器之間的通信，這些通信是獨立于頁面進行的，我們在拖拽Google Mapl時就會觀察到這一點，此日時的背景拼貼就是獨立進行的，或者在你輸入搜索條目時，輸人框下面也會出現可供你選擇的建議列表。這些異步通信模式在Web2.0風格的網站上日漸普遍。
包含某種異步更新或刷新的應用，有不同的延遲測量指標。我們不能再用“頁面加載時間”了，因為此時流向瀏覽器的是持續的更新流。取而代之的是，我們對“每秒消息數”或“刷新時間”這樣的指標進行測量，其中，“刷新時間”表示的是從用戶做某件事情(在鍵盤上輸入一個字符，拖動地圖)到內容得到刷新(建議列表被刷新，地圖被重繪)之間的延遲。
渲染時間
隨著客戶端越來越復雜，瀏覽器做的也越來越多。有可能是啟動高互聯網應用(RIA)，這些RIAs都是構建在 Flash、Flex、HTML5、Java、Javascript以.及 Silverlight之上的，也可能是運行諸如 Quick Time及 Windows媒體播放器等這樣的插件，甚至決定如何對復雜頁面進行布局也是需要花費時間的。所以，對于大量依賴客戶端進行渲染的網站，就必須考慮這種延遲。
好消息是，在構建網站建設客戶端時，可以在其中包含代碼，對延遲進行測量，然后將數據送回給你，這樣就可以了解，對終端用戶而言，你的應用到底怎么樣。
本文地址：http://knowyourextract.com//article/3343.html
