既然我們講的是如何構建高性能的ASP.NET站點應用，那麼我們就開始涉及網站方面的東西。我們說過，我們會把關注點放在“調優”上面。
在調優的時候，我們沒有必要把事情搞的很複雜，要“由表及裏。從整體到局部”。對於一個站點而言，我們最直接看到的就是網站的頁面。換句話說，如果站點性能處理問題，肯定在頁面上面會有反應。一個最顯而易見的反應就是：頁面加載很慢，半天看不到內容。
此時，我們可以進一步的分析，頁面加載很慢，是什麼原因導致的？
這裏還是從最簡單的方面入手。沒有必要想的很複雜，我們要清楚：頁面是由什麼組成的？
很顯而易見，一個頁面，無非就是由Html文本，圖片或者Flash，還有JS和CSS組成。換句話說，如果頁面加載很慢，那麼問題就出現在這些頁面的這些組成部分上面。
頁面解析過程
爲了更好的說明，我們先來看看一個頁面的加載的過程。
1. 當用戶在瀏覽器地址輸入一個地址，然後enter。
2. 此時瀏覽器首先會去進行域名解析，要麼讀取本地的DNS緩存，或者去遠程網絡上面解析，最後的結果就是把域名對應的IP地址得到。
3. 得到了IP地址之後，瀏覽器就開始發送請求，建立TCP連接，經過三次握手之後，連接就建立了。
4. TCP連接建立之後，瀏覽器就把請求發送過去。
5. 服務端接收到請求之後，就開始處理，例如，如果請求的是一個頁面（不管是動態的還是靜態的），最後的結果就是：服務端把響應發送發送給客戶端。
6. 在響應中，先發送的是響應頭，之後就開始傳遞html內容。
7. Html內容經過網絡傳輸到了客戶端瀏覽器之後，瀏覽器就開始加載網頁的內容，開始呈現。產生的頁面的內容html文本是以流的形式傳遞的，通俗的說就是一點點的傳輸的，直到html文本傳遞完成，此時頁面裏面所有的資源還是沒有加載的，只是頁面的html骨架加載完成了。
所以瀏覽器這邊收到html內容之後就開始解析html，而且是從上到下進行解析的：先解析html標記，然後解析head，然後解析body…
在解析的過程之後，如果遇到要去加載資源的標記，例如<script>,<img> 等，此時瀏覽器再次發送請求，獲取資源。一步步的，最後一直把整個頁面全部解析完成，資源加載完成，展示在用戶眼前。
問題解析
理解了這個過程，我們再次回到之前的問題。我們可以知道頁面中不同的組成部分，對應的問題是不一樣的，大致可以分爲下面幾類：
如果Html的產生過慢，那麼，用戶勢必會花很長時間才能看到頁面。如圖：
同理，如果頁面（頁面的html文本內容）的傳輸過慢，那麼，最後整個頁面的解析也會往後面推遲，最後也導致用戶很長時間之後才能看到頁面，如圖：
另外，圖片和flash等資源的加載有問題，那麼一方面會讓用戶看到這些資源，另外也會增加服務器的負擔。如圖：
Js和css的加載是個特別要注意的問題，因爲js的加載是很“霸道“的：如果此時，在解析頁面的html的時候，看到了<script scr="www.agilesharp.com/js/ag.js/> 此時，瀏覽器就會發送請求去獲取這個腳本，而且此時瀏覽器不會繼續解析後面的頁面內容，而是等到這個js回來之後，才能繼續往下走。這就是爲什麼很多時候我們總是把一些不必要的腳本放在頁面的最後加載的原因。而對於css而言，它不霸道，在加載css的同時，瀏覽器可以繼續往下面走，解析下面的頁面內容。
問題的分類
看完了上面簡單的分析之後，我們可以再次思考，把上面的問題進行分類。因爲上面的問題的產生，肯定有一個最後歸根究底的原因的，我們可以通過上面的分析，把他們這些原因對應上，如圖：
在我們後續的講解中，更多的從上圖中的內容進行討論。
從這裏就驗證了我們之前講述的很多的內容：分析問題要順藤摸瓜，由表及裏的分析.
更多：
構建高性能的ASP.NET應用（一）-先把思路搞對，然後對症下藥