高性能ASP.NET站點(diǎn)構(gòu)建之優(yōu)化HTTP請求
高性能ASP.NET站點(diǎn)構(gòu)建系列文章目錄
- 高性能ASP.NET站點(diǎn)構(gòu)建之開篇
- 高性能ASP.NET站點(diǎn)構(gòu)建之剖析頁面的處理過程
- 高性能ASP.NET站點(diǎn)構(gòu)建之優(yōu)化HTTP請求
- 高性能ASP.NET站點(diǎn)構(gòu)建之細(xì)節(jié)決定成敗
- 高性能ASP.NET站點(diǎn)構(gòu)建之性能調(diào)優(yōu)綜述
- 高性能ASP.NET站點(diǎn)構(gòu)建之識(shí)別性能瓶頸
- 高性能ASP.NET站點(diǎn)構(gòu)建之簡單的優(yōu)化措施
- ASP.NET站點(diǎn)構(gòu)建之減少不必要的請求
- 高性能ASP.NET站點(diǎn)構(gòu)建之托管資源優(yōu)化
- 高性能ASP.NET站點(diǎn)構(gòu)建之監(jiān)測CLR性能
上一篇文章主要講述了請求一個(gè)頁面的過程,同時(shí)也提出了在這個(gè)過程中的一些優(yōu)化點(diǎn),本篇就開始細(xì)化頁面的請求過程并且提出優(yōu)化的方案.同時(shí),在上篇文章中,不少朋友也提出了一些問題,在本篇中也對這些問題給出了回答!
本篇的議題如下:
HTTP請求的優(yōu)化
HTTP請求的優(yōu)化
在一個(gè)網(wǎng)頁的請求過程中,其實(shí)整個(gè)頁面的html結(jié)構(gòu)(就是頁面的那些html骨架)請求的時(shí)間是很短的,一般是占整個(gè)頁面的請求時(shí)間的10%-20%.在頁面加載的其余的時(shí)間實(shí)際上就是在加載頁面中的那些flash,圖片,腳本的資源. 一直到所有的資源載入之后,整個(gè)頁面才能完整的展現(xiàn)在我們面前.
下面,我們就從一個(gè)頁面開始講述:
- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
- <html xmlns="http://www.w3.org/1999/xhtml">
- <head>
- <title>小洋,燕洋天</title>
- <script type="text/javascript" src="../demo.js">
- </script>
- </head>
- <body>
- <div>
- <img src="../images/1.gif" />
- <img src="../images/2.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/3.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/4.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/5.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/6.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/7.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/8.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/7.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/8.gif" />
- </div>
- </body>
- </html>
如果我們向服務(wù)器請求這個(gè)頁面,客戶端的瀏覽器首先請求到的數(shù)據(jù)就是html骨架,即:
- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
- <html xmlns="http://www.w3.org/1999/xhtml">
- <head>
- <title>小洋,燕洋天</title>
- <script type="text/javascript" src="../demo.js">
- </script>
- </head>
- body>
- <div>
- <img src="../images/1.gif" />
- <img src="../images/2.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/3.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/4.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/5.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/6.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/7.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/8.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/7.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/8.gif" />
- </div>
- </body>
- </html>
在此之前,首先來普及一下頁面加載的小知識(shí):
當(dāng)頁面的html骨架載入了之后,瀏覽器就開始解析頁面中標(biāo)簽,從上到下開始解析.
首先是head標(biāo)簽的解析,如果發(fā)現(xiàn)在head中有要引用的js腳本,那么瀏覽器此時(shí)就開始請求腳本,此時(shí)整個(gè)頁面的解析過程就停了下來,一直到j(luò)s請求完畢.
之后頁面接著向下解析,如解析body標(biāo)簽,如果在body中有img標(biāo)簽,那么瀏覽器就會(huì)請求img的src對應(yīng)的資源,如果有多個(gè)img標(biāo)簽,那么瀏覽器就一個(gè)個(gè)的解析,解析不會(huì)像js那樣等待的,如果發(fā)現(xiàn)img的url地址是同一個(gè)地址,那么瀏覽器就會(huì)充分的利用這個(gè)已經(jīng)打開的tcp連接順序的去一個(gè)個(gè)的請求圖片,如果發(fā)現(xiàn)有的img的url地址不同,那么瀏覽器就另開tcp連接,發(fā)送http請求.
注意之前請求js的區(qū)別:請求需要js,瀏覽器會(huì)一直等待,不在解析下面的html標(biāo)簽
但是解析到img的時(shí)候,盡管此時(shí)需要加載圖片,但是頁面的解析過程還是會(huì)繼續(xù)下去的,然后決定是否發(fā)送新的tcp連接加載資源.
大家可能覺得這個(gè)之前的代碼片段一樣,確實(shí)代碼是一樣的,但是,在最開始的時(shí)候,發(fā)送到瀏覽器中的只是那些html的代碼,任何的js腳本和圖片還沒有發(fā)送過來.
當(dāng)html代碼到了瀏覽器中,那么瀏覽器就開始一步步的解析這些代碼了,只要遇到了需要加載的資源,瀏覽器就向服務(wù)器發(fā)出http請求,請求所需的資源.
整個(gè)頁面的加載時(shí)間圖如下:
大家從圖中可以看出:
第一條線中分為一半黃色和一半藍(lán)色,其實(shí)黃色的部分就代表了打開一個(gè)tcp連接花的時(shí)間,而后面的藍(lán)色的部分就是請求整個(gè)html骨架文檔的時(shí)間.可以看出,請求html骨架的時(shí)間是很短的.其余藍(lán)色的線就表示了圖片,腳本資源加載所花的時(shí)間.
很顯然,這樣頁面的整個(gè)加載時(shí)間就很長了.因?yàn)轫撁娴募虞d幾乎是順序的載入,時(shí)間就是所有資源加載時(shí)間的總和.
下面我們把上面的頁面代碼代為如下:
- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
- <html xmlns="http://www.w3.org/1999/xhtml">
- <head>
- <title>小洋,燕洋天</title>
- <script type="text/javascript" src="../demo.js">
- </script>
- </head>
- <body>
- <div>
- <img src="http://demo1.com/images/1.gif" />
- <img src="http://demo1.com/images/2.gif" />
- <img src="http://demo2.com/image/3.gif" />
- <img src="http://demo2.com/image/4.gif" />
- <img src="http://demo3.com/image/5.gif" />
- <img src="http://demo3/image/6.gif" />
- <img src="http://demo4.com/image/7.gif" />
- <img src="http://demo4.com/image/8.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/7.gif" />
- <img src="http://yanyangtian.cnblogs.com/image/8.gif" />
- </div>
- </body>
- </html>
我們再來看看頁面的加載時(shí)間圖
這就是所謂的”并行”載入了.
比較一下兩段代碼的不同:其實(shí)就在img的src屬性上面:
第一段頁面的代碼:img的src屬性都是指向一個(gè)域名的.
第二段頁面的代碼:img的src屬性指向了不同的域名
這樣做的結(jié)果是什么?
請大家注意比較img的src的不同.
解釋之前,首先來看一個(gè)小的常識(shí)(在上篇文章中也提過):
當(dāng)頁面請求向服務(wù)器請求資源的時(shí)候,如果瀏覽器已經(jīng)在客戶端和服務(wù)器之前打開了一個(gè)tcp連接,而且請求的資源也在開了連接的服務(wù)器上,那么以后資源的請求就會(huì)充分的利用這個(gè)連接去獲取資源. 這樣也就是第一個(gè)時(shí)間圖的由來.
如果請求的圖片分別位于不同的服務(wù)器網(wǎng)站,或者那個(gè)請求的服務(wù)器網(wǎng)站有多個(gè)域名,那么因?yàn)闉g覽器就會(huì)為每一個(gè)域名去開一個(gè)tcp連接,發(fā)送http請求,這樣,結(jié)果就是同時(shí)開了多tcp連接,這也是第二個(gè)時(shí)間圖的由來.
雖然說并行加載,確實(shí)使得頁面的載入快了不少,但是也不是每一個(gè)圖片或者其他的資源都去搞一個(gè)不同的域名,像之前的第二個(gè)并行載入圖片的例子,也是讓兩個(gè)圖片利用一個(gè)tcp連接.如果每個(gè)圖片都去開一個(gè)連接,這樣瀏覽器就開了很多個(gè)連接,也是很費(fèi)資源的,而且瀏覽器還可能會(huì)”僵死”.而且有時(shí)還會(huì)嚴(yán)重的影響性能.
所以,這是需要權(quán)衡的.
除了上面的優(yōu)化方式,還有其他的圖片優(yōu)化的加載方式.主要是通過減少http的請求達(dá)到優(yōu)化
大家都知道網(wǎng)站的一個(gè)menu菜單,有些菜單就是用圖片作出來的.如
如果上面的圖片一個(gè)個(gè)載入,勢必影響速度,如果開多和請求,有點(diǎn)得不償失.而且圖片也不是很大,那么就一次把整個(gè)menu需要的圖片作為整個(gè)圖片,一次加載,然后通過map的方式,控制點(diǎn)擊圖片的位置來達(dá)到導(dǎo)航的效果.
這樣一個(gè)問題就是:算出圖片的坐標(biāo),不能點(diǎn)擊了”主頁”圖片,然后卻跳到了”幫助”頁面了.
本篇就講述到這里,下篇講述其他的資源文件的優(yōu)化,希望 多多提出建議,爭取把這個(gè)系列寫好!
原文鏈接:http://www.cnblogs.com/yanyangtian/archive/2010/07/28/1786720.html
【編輯推薦】