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