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的方式,控制点击图片的位置来达到导航的效果.

　　这样一个问题就是:算出图片的坐标,不能点击了”主页”图片,然后却跳到了”帮助”页面了.

ASP.NET 构建高性能网站 第3篇的更多相关文章

  1. ASP.NET 构建高性能网站 第2篇

    前言:在对ASP.NET网站进行优化的时候,往往不是只是懂得ASP.NET就足够了的. 在优化的过程中,一般先是找出问题可能存在的地方,然后证明找出的问题就是要解决的问题,确认之后,在进行一些措施.系 ...

  2. ASP.NET 构建高性能网站 第5篇

    利用分析工具分析加载页面信息 站点的优化说到底还是站点每一个页面的优化,即使得站点的页面更快的呈现在用户的眼前.所以在此之前,我们首先来看看一个web页面的组成部分: 1. Html文件:在ASP.N ...

  3. ASP.NET 构建高性能网站 第1篇

    网站优化需要考虑的方面 在用ASP.NET开发网站的时候,性能是永远需要考虑和关注的问题,性能不仅仅只是程序代码执行时候的速度,而是涉及到方方面面的东西. 就拿ASP.NET的一个请求来讲,从浏览器向 ...

  4. ASP.NET 构建高性能网站 第4篇

    部署优化 我们都知道,不同的部署方式对站点的性能是有影响的,可能有些朋友已经知道了这点,不管怎样,我们这里还是详细系统的讲述一下这个问题,熟悉的朋友权当回顾J. Release方式编译项目 如果我们的 ...

  5. ASP.NET 构建高性能网站 第6篇

    内存问题概述 和CPU一样,内存也是一个直接影响服务端性能的重要的硬件资源. 一般来说,如果服务端内存不足,从导致以下两个问题产生: 1.       导致服务端把一些原本要写到内存中的数据,写到硬盘 ...

  6. ASP.NET 构建高性能网站 架构设计

    Web前端系统 为了达到不同应用的服务器共享.避免单点故障.集中管理.统一配置等目的,不以应用划分服 务器,而是将所有服务器做统一使用,每台服务器都可以对多个应用提供服务,当某些应用访问量升高时,通过 ...

  7. MySQL全面瓦解24：构建高性能索引（策略篇）

    学习如果构建高性能的索引之前,我们先来了解下之前的知识,以下两篇是基础原理,了解之后,对面后续索引构建的原则和优化方法会有更清晰的理解: MySQL全面瓦解22:索引的介绍和原理分析 MySQL全面瓦 ...

  8. 高性能网站架构设计之缓存篇（5）- Redis 集群（上）

    集群技术是构建高性能网站架构的重要手段,试想在网站承受高并发访问压力的同时,还需要从海量数据中查询出满足条件的数据,并快速响应,我们必然想到的是将数据进行切片,把数据根据某种规则放入多个不同的服务器节 ...

  9. MySQL全面瓦解25：构建高性能索引（案例分析篇）

    回顾一下上面几篇索引相关的文章: MySQL全面瓦解22:索引的介绍和原理分析 MySQL全面瓦解23:MySQL索引实现和使用 MySQL全面瓦解24:构建高性能索引(策略篇) 索引的十大原则 1. ...

随机推荐

  1. 五、springboot单元测试

    1.为什么要写测试用例 1. 可以避免测试点的遗漏,为了更好的进行测试,可以提高测试效率 2. 可以自动测试,可以在项目打包前进行测试校验 3. 可以及时发现因为修改代码导致新的问题的出现,并及时解决 ...

  2. 使用JS实现文字搬运工

    使用JS实现文字搬运工 效果图: 代码如下,复制即可使用: <!DOCTYPE html> <html><head><meta http-equiv=&quo ...

  3. Codeforces 264B Good Sequences(DP+素数筛)

    题目链接:http://codeforces.com/problemset/problem/264/B 题目大意:给出n个单调递增的数,让你找出最长的好序列,好序列是一种单调递增的并且相邻元素的最大公 ...

  4. Java事务管理之JDBC

    前言 关于Java中JDBC的一些使用可以参见: Java 中使用JDBC连接数据库例程与注意事项 在使用JDBC的使用, 如何进行事务的管理.直接看一下代码 示例代码 /** * @Title: J ...

  5. 利用Octopress在github pages上搭建个人博客

    利用Octopress在github pages上搭建个人博客 SEP 29TH, 2013 在GitHub Pages上用Octopress搭建博客,需要安装ruby环境.git环境等.本人在Fed ...

  6. 1975: [Sdoi2010]魔法猪学院

    k短路,只会写A*的飘过..priority_queue超空间差评!

  7. 矩阵链乘（UVa 442)

    结构体 struct matrix 用来保存矩阵的行和列: map<string,matrix> 用来保存矩阵名和相应的行列数: stack<string> 用来保存表达式中遇 ...

  8. HDU - 4420 2013icpc长春A 函数离散化 + st表

    思路:我们定义F(x) 为以x点为起点,向后(a - b)个里面有多少个白球,虽然x的范围是LL范围内的,但是白球的 个数只有1e5, 那么我们可以把连续一段相同的离散化到一起, 对于一个确定的长度为 ...

  9. 使用easypoi导出excel

    EasyPOI是在jeecg的poi模块基础上,继续开发独立出来的,可以说是2.0版本,EasyPoi封装的目的和jeecg一致,争取让大家write less do more ,在这个思路上easy ...

  10. [漏洞复现] CVE-2017-11882 通杀所有Office版本

    此漏洞是由Office软件里面的 [公式编辑器] 造成的,由于编辑器进程没有对名称长度进行校验,导致缓冲区溢出,攻击者通过构造特殊的字符,可以实现任意代码执行. 举个例子,如果黑客利用这个漏洞,构造带 ...