高性能WEB开发 为什么要减少请求数,如何减少请求数!

http请求头的数据量

我们先分析下请求头,看看每次请求都带了那些额外的数据.下面是监控的google的请求头

Host www.google.com.hk
User-Agent Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 GTBDFff GTB7.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language zh-cn,en-us;q=0.7,en;q=0.3
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Proxy-Connection keep-alive

返回的response head

Date Sat, 17 Apr 2010 08:18:18 GMT
Expires -1
Cache-Control private, max-age=0
Content-Type text/html; charset=UTF-8
Set-Cookie PREF=ID=b94a24e8e90a0f50:NW=1:TM=1271492298:LM=1271492298:S=JH7CxsIx48Zoo8Nn; expires=Mon, 16-Apr-2012 08:18:18 GMT; path=/; domain=.google.com.hk NID=33=EJVyLQBv2CSgpXQTq8DLIT2JQ4aCAE9YKkU2x-h4hVw_ATrGx7njA69UUBMbzVHVnkAOe_jlGGzOoXhQACSFDP1i53C8hWjRTJd0vYtRNWhGYGv491mwbngkT6LCYbvg; expires=Sun, 17-Oct-2010 08:18:18 GMT; path=/; domain=.google.com.hk; HttpOnly
Content-Encoding gzip
Server gws

Content-Length 4344

这里发送的请求头的大小大概420 bytes,返回的请求头大概 600 bytes。

可见每次请求都会带上一些额外的信息进行传输(这次请求中还没有带cookie),当请求的资源很小,比如1个不到1k的图标,可能request带的数据比实际图标的数据量还大。

所以当请求越多的时候,在网络上传输的数据自然就多,传输速度自然就慢了。

其实request自带的数据量还是小问题,毕竟request能带的数据量还是有限的。

http连接的开销

相比request头部多余的数据,http连接的开销则更加严重。先看看从用户输入1个URL到下载内容到客户端需要经过哪些阶段:

1. 域名解析
2. 开启TCP连接
3. 发送请求
4. 等待(主要包括网络延迟和服务器处理时间)
5. 下载资源

可能很多人认为每次请求大部分时间都花在下载资源上,让我们看看blogjava资源下载瀑布图(每种颜色代表的阶段与上面5个阶段对应):

看了上图你可能惊讶,花费在等待阶段的时间比实际下载的时间要多的多,上图告诉我们:
1. 每次请求花费的大部分时间在其他阶段,而不是在下载资源阶段
2. 再小的资源照样会花费很多时间在其他阶段,只是下载阶段会比较短(见上图的第6个资源,才284Byte)。

正对上面提到的2种情况,我们应该要怎么进行优化了?减少请求数来减少其他阶段的花销和网络中传输的数据。

如何减少请求数

1、合并文件
合并文件就是把很多JS文件合并成1个文件,很多CSS文件合并成1个文件,这种方法应该很多人用到过,这里不做详细介绍,
只推荐1个合并的工具:yuiCompressor 这个工具yahoo提供的。 http://developer.yahoo.com/yui/compressor/

2、合并图片
这是利用css sprite,通过控制背景图片的位置来显示不同的图片。这种技术也是大家都用过的,不做详细介绍,推荐1个在线合并图片的网站:http://csssprites.com/

3、把JS、CSS合并到1个文件
上面第1种方法说的只是把几个JS文件合并成1个JS文件,几个CSS文件合并成1个CSS文件,哪如何把CSS和JS都合并到1个文件中,见我的另1篇文章:
http://www.blogjava.net/BearRui/archive/2010/04/18/combin_css_js.html

4、使用Image maps
Image maps 是把多个图片合并成1个图片,然后使用html中的<map>标签连接图片,并实现点击图片不同的区域执行不同的动作,image map在导航条中比较容易使用到。
image map的使用方法见: http://www.w3.org/TR/html401/struct/objects.html#h-13.6

5、data嵌入图片
这种方法把图片进行编码直接嵌入到html中进行使用,以减少HTTP请求,但这个会增加HTML页面的大小,而且这样嵌入的图片不能缓存。见下面这个图片:

上面的图片就是把图片进行base64编码后使用data:嵌入到html中,代码如下(后面的省略了,大家可以查看源代码看):
<IMG SRC="data:image/gif;base64,/9j/4AAQSkZJRgABAQEAYABgAAD/4QAWRXhpZgAASUkqAAgAA......">

其中google的视频搜索中,搜索出来的视频缩略图就都是使用嵌入的图片的,见下图:


以上几种方法在都有利有弊,在不同情况下可以选择不同的使用方式,比如使用data嵌入图片虽然减少了请求数,但会增加页面大小。

所以微软的bing搜索在用户第一次访问的时候使用data嵌入图片,然后后台懒加载真真的图片,以后访问就直接使用缓存的图片,而不使用data。

[声明] 转载请注明出处:http://www.blogjava.net/BearRui/。 禁止商用!

(0)

相关推荐

  • WEB高性能开发之疯狂的HTML压缩

    一般我们启动gzip都比较少对html启动gzip,因为现在的html都是动态的,不会使用浏览器缓存,而启用gzip的话每次请求都需要压缩,会比较消耗服务器资源,对js,css启动gzip比较好是因为js,css都会使用缓存.我个人觉得的压缩html的最大好处就是一本万利,只要写好了一次,以后所有程序都可以使用,不会增加任何额外的开发工作. 在"JS.CSS的合并.压缩.缓存管理"一文中说到自己写过的1个自动合并.压缩JS,CSS,并添加版本号的组件.这次把压缩html的功能也加入到该

  • 高性能WEB开发 flush让页面分块,逐步呈现 flush让页面分块,逐步呈现

    一般大家在处理这种情况,都使用ajax,先把html输出到客户端,然后再用ajax取加载比较耗时的资源.用ajax麻烦的地方是增加了请求数,而且需要写额外的js代码.和js调用的请求接口. 正对这种情况,还有一种处理方法,就是让response分块编码进行传输.response分块编码,可以先传输一部分不需要处理的html代码到客户端,等其他耗时代码执行完毕后再传输另外的html代码. 分块编码(chunked encoding) chunked encoding 是http1.1 才支持编码格

  • 高性能WEB开发 页面呈现、重绘、回流。

    页面呈现流程 在讨论页面重绘.回流之前.需要对页面的呈现流程有些了解,页面是怎么把html结合css等显示到浏览器上的,下面的流程图显示了浏览器对页面的呈现的处理流程.可能不同的浏览器略微会有些不同.但基本上都是类似的. 1. 浏览器把获取到的html代码解析成1个Dom树,html中的每个tag都是Dom树中的1个节点,根节点就是我们常用的document对象(<html> tag).dom树就是我们用firebug或者IE Developer Toolbar等工具看到的html结构,里面包

  • 高性能WEB开发 web性能测试工具推荐

    Firebug:    Firebug 是firefox中最为经典的开发工具,可以监控请求头,响应头,显示资源加载瀑布图: HttpWatch :   httpwatch 功能类似firebug,可以监控请求头,响应头,显示资源加载瀑布图.但是httpwatch还能显示GZIP压缩信息,DNS查询,TCP链接信息,个人在监控http请求比较喜欢使用httpwatch, httpwatch包含IE和firefox插件.不过httpwatch专业版本是收费的,免费版本有些功能限制. DynaTrac

  • 高性能web开发 如何加载JS,JS应该放在什么位置?

    外部JS的阻塞下载 所有浏览器在下载JS的时候,会阻止一切其他活动,比如其他资源的下载,内容的呈现等等.至到JS下载.解析.执行完毕后才开始继续并行下载其他资源并呈现内容. 有人会问:为什么JS不能像CSS.image一样并行下载了?这里需要简单介绍一下浏览器构造页面的原理, 当浏览器从服务器接收到了HTML文档,并把HTML在内存中转换成DOM树,在转换的过程中如果发现某个节点(node)上引用了CSS或者IMAGE,就会再发1个request去请求CSS或image,然后继续执行下面的转换,

  • 高性能WEB开发 JS、CSS的合并、压缩、缓存管理

    存在的问题: 合并.压缩文件主要有2方面的问题: 1. 每次发布的时候需要运行一下自己写的bat文件或者其他程序把文件按照自己的配置合并和压缩. 2. 因生产环境和开发环境需要加载的文件不一样,生产环境为了需要加载合并.压缩后的文件,而开发环境为了修改.调试方便,需要加载非合并.压缩的文件,所以我们常常需要在JSP中类似与下面的判断代码: 复制代码 代码如下: <c:if test="${env=='prod'}"> <script type="text/j

  • 高性能WEB开发 图片压缩篇

    一.缩小图片大小 当图片很多的时候,减少图片大小是提高下载速度最直接的方法. 1. 使用PNG8代替GIF(非动画图片),因为PNG8在效果一样的情况,图片大小比GIF要小. 2. 用fireworks处理PNG图片,在我们产品中很多PNG图片是美工直接用photoshop导出的, 后来让美工用fireworks处理PNG(大概的方式是选择保存为PNG8,删除背景色). 处理后100K的图片大小基本减少了3/4,但图片质量也会有少许降低,要看自己是否能接受. 3. 使用Smush.it(http

  • 高性能WEB开发(5) 减少请求,响应的数据量

    GZIP压缩    gzip是目前所有浏览器都支持的一种压缩格式,IE6需要SP1及以上才支持(别说你还在用IE5,~_~).gzip可以说是最方便而且也是最大减少响应数据量的1种方法. 说它方便,是因为你不需要为它写任何额外的代码,只需要在http服务器上加上配置都行了,现在主流的http服务器都支持gzip,各种服务器的配置这里就不一一介绍(其实是我不知道怎么配), nginx的配置可以参考我这篇文章:www.blogjava.net/BearRui/archive/2010/01/29/w

  • 编写高性能的JavaScript 脚本的加载与执行

    脚本可以放在html页面的head里面,也可以放在body里面. 把脚本放在body中,当浏览器遇见<script>标签时, 浏览器不知道脚本会插入文本还是html标签,因此浏览器会停止分析html页面而去执行脚本.当使用src的方式添加脚本时,浏览器也会做同样的动作.在脚本处理的时候,页面呈现和用户交互将被完全阻止.脚本下载和执行阻塞了其他资源的下载,比如呈现页面使用的图片.(虽然很多浏览器实现了脚本并行下载的技术,但是这个问题依然没有解决) 脚本的位置 鉴于上面的理由,脚本应该始终放在页面

  • web高性能开发系列随笔 BearRui(AK-47)版

    1. HTTP服务器.2.性能测试工具推荐 3. 图片篇. 4. 如何加载JS,JS应该放在什么位置. 5. 为什么要减少请求数,如何减少请求数.6. 减少请求,响应的数据量.7.JS.CSS的合并.压缩.缓存管理 8.页面呈现.重绘.回流. 9.该如何加载google-analytics(或其他第三方)的JS. [声明] 转载请注明出处:http://www.cnblogs.com/BearsTaR/. 禁止商用!

  • 高性能WEB开发 nginx HTTP服务器篇

    第一篇:HTTP服务器 因tomcat处理静态资源的速度比较慢,所以首先想到的就是把所有静态资源(JS,CSS,image,swf) 提到单独的服务器,用更加快速的HTTP服务器,这里选择了nginx了,nginx相比apache,更加轻量级, 配置更加简单,而且nginx不仅仅是高性能的HTTP服务器,还是高性能的反向代理服务器. 目前很多大型网站都使用了nginx,新浪.网易.QQ等都使用了nginx,说明nginx的稳定性和性能还是非常不错的. 1. nginx 安装(linux) htt

  • 了解CSS的查找匹配原理,让CSS更简洁、高效

    看1个简单的CSS: DIV#divBox p span.red{color:red;},按习惯我们对这个CSS 的理解是,浏览器先查找id为divBox的DIV元素,当找到后,再找其下的所有p元素,然后再查找所有span元素,当发现有span的class为red的时候,就应用该style.多么简单易懂的原理,可是这个理解却是完完全全相反.错误的. 匹配原理: 浏览器CSS匹配不是从左到右进行查找,而是从右到左进行查找.比如之前说的 DIV#divBox p span.red{color:red

随机推荐