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

GZIP压缩
    gzip是目前所有浏览器都支持的一种压缩格式,IE6需要SP1及以上才支持(别说你还在用IE5,~_~)。gzip可以说是最方便而且也是最大减少响应数据量的1种方法。

说它方便,是因为你不需要为它写任何额外的代码,只需要在http服务器上加上配置都行了,现在主流的http服务器都支持gzip,各种服务器的配置这里就不一一介绍(其实是我不知道怎么配),

nginx的配置可以参考我这篇文章:www.blogjava.net/BearRui/archive/2010/01/29/web_performance_server.html

我们先看看gzip的压缩比率能达到多少,这里用jquery 1.4.2的min和src2个版本进行测试,使用nginx服务器,gzip压缩级别使用的是4:


   注意看上图的红色部分,jquery src文件在启用gzip后大小减少了70%


   这张图片可以看出就算是已经压缩过min.js在启用gzip后大小也减少了65%。

别对图片启用gzip

在知道了gzip强大的压缩能力后,你是否想对服务器上的所有文件启用gzip了,先让我们看看图片中启用gzip后会是什么情况。

hoho,1个gif图片经过gzip压缩后反而变大了???这是因为图片本来就是一种压缩格式,gzip不能再进行压缩,反而会添加1些额外的头部信息,所以图片会变大。

在测试过程中,发现jpg的图片经过gzip压缩后会变小,不知道为何,可能跟图片压缩方式有关。不过压缩比率也比较小,所以就算是jpg,建议也不要开启gzip压缩。

比较适合启用gzip压缩的文件有如下这些:

1. javascript

2. CSS

3. HTML,xml

4、plain text

别乱用cookie
     现在几乎没有哪个网站不使用cookie了,可是该怎么使用cookie比较合适了,cookie有几个重要的属性:path(路径),domain(域),expires(过期时间)。浏览器就是根据这3个属性来判断在发送请求的时候是否需要带上这个cookie。
     cookie使用最好的方式,就是当请求的资源需要cookie的时候才带上该cookie。其他任何请求都不带上cookie。但事实上很多人在使用cookie的时候已经习惯性的设置成:path=/ domain=.domain.com。这样的结果就是不管任何请求都会带上cookie,就算你是请求的图片(img.domain.com)、静态资源服务器(res.domain.com)这些根本不需要cookie的资源,浏览器照样会带上这些没用的cookie。咱们一起来看现实中的1个列子,博客园(www.cnblogs.com):

先看看博客园的cookie是怎么设置的,下面是firefox查看博客园cookie的截图:


   cnblogs总共有5个cookie值,而且全部设置都是  path=/ domain=.cnblogs.com。知道了cookie的设置后,我们再来监控下博客园首页的请求,监控的统计信息如下:

总请求数:39(其中图片22个,JS7个,css2个)。

其中js、css、image 主要来自3个静态资源服务器: common.cnblogs.com , pic.cnblogs.com ,static.cnblogs.com

   再看其中1个请求图片(/upload/201005/20100514004349115.gif)的请求头:

Host static.cnblogs.com

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 image/png,image/*;q=0.8,*/*;q=0.5

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

Referer http://www.cnblogs.com/

Cookie __gads=ID=a15d7cb5c3413e56:T=1272278620:S=ALNI_MZNMr6_d_PCjgkJNJeEQXkmZ3bxTQ; __utma=226521935.1697566422.1272278366.1272278366.1272278366.1; __utmb=226521935.2.10.1272278366; __utmc=226521935; __utmz=226521935.1272278367.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)

我们发现在请求banner_job.gif这个图片的时候,浏览器把cnblogs.com的所有cookie都带上了(其他图片的请求都是一样的),我估计博客园在处理图片的时候应该不需要用到cookie吧?也许你认为这几个cookie的大小只有300个字节左右,无所谓啦。

我们做个简单的计算,假设博客园每天有50W个PV(实际情况应该不止吧),每次PV大概有15次请求静态资源,15*500000*300/1024/1024=2145M。也就说这几个cookie每天大概会耗费博客园2G的带宽。当然这种简单的计算方式肯定会有偏差,毕竟我们还没把静态资源缓存考虑进去。但是个人觉得要是博客园要是把cookie的domain设置为www.cnblogs.com会更好一些。

妙用204状态
    http中200,404,500状态大家都很清楚,但204状态大家可能用的比较少,204状态是指服务器成功处理了客户端请求,但服务器无返回内容。204是HTTP中数据量最少的响应状态,204的响应中没有body,而且Content-Length=0。很多人在使用ajax提交一些数据给服务器,而不需要服务器返回的时候,常常在服务端使用下面的代码:response.getWriter().print(""),这是返回1个空白的页面,是1个200请求。它还是有body,而且Content-Length不会等于0。其实这个时候你完全可以直接返回1个204状态(response.setStatus(204))。204在一些网站分析的代码中最常用到,只需要把客户端的一些信息提交给服务器就完事,让我们看看google首页的1个204响应,google首页的最后1个请求返回的就是204状态,但这个请求是干嘛用的就没猜出来了:


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

(0)

相关推荐

  • 了解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

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

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

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

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

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

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

  • 高性能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开发 为什么要减少请求数,如何减少请求数!

    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

  • 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开发 web性能测试工具推荐

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

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

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

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

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

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

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

随机推荐