如何开始寻找性能瓶颈
既然我们讲的是如何构建高性能的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应用（一）-先把思路搞对，然后对症下药
构建高性能的ASP.NET应用（三）-从监控出发，让一切用数据说话