【原創】構建高性能ASP.NET站點之二優化HTTP請求(前端)

時間 2019-11-08

標籤原創構建高性能 asp.net asp 站點之二優化 http 請求前端欄目 ASP 简体版

原文原文鏈接

構建高性能ASP.NET站點之二優化HTTP請求(前端)javascript

　　前言: 這段時間比較的忙,文章寫不是很勤,但願你們諒解.html

　　上一篇文章主要講述了請求一個頁面的過程,同時也提出了在這個過程當中的一些優化點,本篇就開始細化頁面的請求過程而且提出優化的方案.同時,在上篇文章中,很多朋友也提出了一些問題,在本篇中也對這些問題給出了回答!前端

　　系列文章連接：java

　　構建高性能ASP.NET站點開篇瀏覽器

　　構建高性能ASP.NET站點之一剖析頁面的處理過程（前端）服務器

　　構建高性能ASP.NET站點之二優化HTTP請求(前端) 架構

　　構建高性能ASP.NET站點之三細節決定成敗 tcp

　　構建高性能ASP.NET站點第五章—性能調優綜述（前篇） post

　　大型高性能ASP.NET系統架構設計性能

　　構建高性能ASP.NET站點第五章—性能調優綜述（中篇）

　　構建高性能ASP.NET站點第五章—性能調優綜述（後篇）

　　構建高性能ASP.NET站點第六章—性能瓶頸診斷與初步調優（上篇）—識別性能瓶頸

　　構建高性能ASP.NET站點第六章—性能瓶頸診斷與初步調優（下前篇）—簡單的優化措施

　　構建高性能ASP.NET站點第六章—性能瓶頸診斷與初步調優（下後篇）—減小沒必要要的請求

　　構建高性能ASP.NET站點第七章如何解決內存的問題(前篇)—託管資源優化—垃圾回收機制深度剖析

　　構建高性能ASP.NET站點第七章如何解決內存的問題(前中篇)—託管資源優化—監測CLR性能

　　本篇的議題以下:

　　HTTP請求的優化

　　HTTP請求的優化

　　在一個網頁的請求過程當中,其實整個頁面的html結構(就是頁面的那些html骨架)請求的時間是很短的,通常是佔整個頁面的請求時間的10%-20%.在頁面加載的其他的時間實際上就是在加載頁面中的那些flash,圖片,腳本的資源. 一直到全部的資源載入以後,整個頁面才能完整的展示在咱們面前.

　　下面,咱們就從一個頁面開始講述:

1 <! DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
2 < html xmlns ="http://www.w3.org/1999/xhtml" >
3 < head >
4      < title > 小洋,燕洋天 </ title >
5
6      < script type ="text/javascript" src ="../demo.js" >
7      </ script >
8
9 </ head >
10 < body >
11      < div >
12          < img src ="../images/1.gif" />
13          < img src ="../images/2.gif" />
14          < img src ="http://yanyangtian.cnblogs.com/image/3.gif" />
15          < img src ="http://yanyangtian.cnblogs.com/image/4.gif" />
16          < img src ="http://yanyangtian.cnblogs.com/image/5.gif" />
17          < img src ="http://yanyangtian.cnblogs.com/image/6.gif" />
18          < img src ="http://yanyangtian.cnblogs.com/image/7.gif" />
19          < img src ="http://yanyangtian.cnblogs.com/image/8.gif" />
20          < img src ="http://yanyangtian.cnblogs.com/image/7.gif" />
21          < img src ="http://yanyangtian.cnblogs.com/image/8.gif" />
22      </ div >
23 </ body >
24 </ html >
25

　　若是咱們向服務器請求這個頁面,客戶端的瀏覽器首先請求到的數據就是html骨架,即:

　　在此以前,首先來普及一下頁面加載的小知識:

當頁面的html骨架載入了以後,瀏覽器就開始解析頁面中標籤,從上到下開始解析.

首先是head標籤的解析,若是發如今head中有要引用的js腳本,那麼瀏覽器此時就開始請求腳本,此時整個頁面的解析過程就停了下來,一直到js請求完畢.

以後頁面接着向下解析,如解析body標籤,若是在body中有img標籤,那麼瀏覽器就會請求img的src對應的資源,若是有多個img標籤,那麼瀏覽器就一個個的解析,解析不會像js那樣等待的,若是發現img的url地址是同一個地址,那麼瀏覽器就會充分的利用這個已經打開的tcp鏈接順序的去一個個的請求圖片,若是發現有的img的url地址不一樣,那麼瀏覽器就另開tcp鏈接,發送http請求.

注意以前請求js的區別:請求須要js,瀏覽器會一直等待,不在解析下面的html標籤

可是解析到img的時候,儘管此時須要加載圖片,可是頁面的解析過程仍是會繼續下去的,而後決定是否發送新的tcp鏈接加載資源.

　　你們可能以爲這個以前的代碼片斷同樣,確實代碼是同樣的,可是,在最開始的時候,發送到瀏覽器中的只是那些html的代碼,任何的js腳本和圖片尚未發送過來.

　　當html代碼到了瀏覽器中,那麼瀏覽器就開始一步步的解析這些代碼了,只要遇到了須要加載的資源,瀏覽器就向服務器發出http請求,請求所需的資源.

　　整個頁面的加載時間圖以下:

　　你們從圖中能夠看出:

　　第一條線中分爲一半黃色和一半藍色,其實黃色的部分就表明了打開一個tcp鏈接花的時間,然後面的藍色的部分就是請求整個html骨架文檔的時間.能夠看出,請求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 ="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 >

　　咱們再來看看頁面的加載時間圖

　　這就是所謂的」並行」載入了.

　　比較一下兩段代碼的不一樣:其實就在img的src屬性上面:

　　　　第一段頁面的代碼:img的src屬性都是指向一個域名的.

　　　　第二段頁面的代碼:img的src屬性指向了不一樣的域名

　　這樣作的結果是什麼?

　　請你們注意比較img的src的不一樣.

　　解釋以前,首先來看一個小的常識(在上篇文章中也提過):

當頁面請求向服務器請求資源的時候,若是瀏覽器已經在客戶端和服務器以前打開了一個tcp鏈接,並且請求的資源也在開了鏈接的服務器上,那麼之後資源的請求就會充分的利用這個鏈接去獲取資源. 這樣也就是第一個時間圖的由來.

若是請求的圖片分別位於不一樣的服務器網站,或者那個請求的服務器網站有多個域名,那麼由於瀏覽器就會爲每個域名去開一個tcp鏈接,發送http請求,這樣,結果就是同時開了多tcp鏈接,這也是第二個時間圖的由來.

　　雖說並行加載,確實使得頁面的載入快了很多,可是也不是每個圖片或者其餘的資源都去搞一個不一樣的域名,像以前的第二個並行載入圖片的例子,也是讓兩個圖片利用一個tcp鏈接.若是每一個圖片都去開一個鏈接,這樣瀏覽器就開了不少個鏈接,也是很費資源的,並且瀏覽器還可能會」僵死」.並且有時還會嚴重的影響性能.

　　因此,這是須要權衡的.

　　除了上面的優化方式,還有其餘的圖片優化的加載方式.主要是經過減小http的請求達到優化

　　你們都知道網站的一個menu菜單,有些菜單就是用圖片做出來的.如

　　若是上面的圖片一個個載入,勢必影響速度,若是開多和請求,有點得不償失.並且圖片也不是很大,那麼就一次把整個menu須要的圖片做爲整個圖片,一次加載,而後經過map的方式,控制點擊圖片的位置來達到導航的效果.

　　這樣一個問題就是:算出圖片的座標,不能點擊了」主頁」圖片,而後卻跳到了」幫助」頁面了.

　　本篇就講述到這裏,下篇講述其餘的資源文件的優化,但願多多提出建議,爭取把這個系列寫好!

版權爲小洋和博客園全部，歡迎轉載，轉載請標明出處給做者。

　　 http://www.cnblogs.com/yanyangtian

　　另外補上網友發的信息：

#21樓 2010-07-28 14:51 | leening

我通常處理圖片的方式是叫美工把全部的小圖片合成一張大的圖片，加載到頁面，而後用CSS去定位，固然用map的方式是能夠的，可是用CSS的方式來的快且方便，參考代碼以下：
div{ background:#FFF url(image) no-repeat fixed x y;}
x,y表示背景圖片的定位，而不須要是座標，具體可參考以下連接：
http://www.dwww.cn/news/2009-3/20093111943478871.shtml

謝謝