web系统性能优化.docx

WEB站点性能优化
由于较少的接触WAP站点的建设，缺乏类似站点的建设经验，导致后期的性能问题成了影响项目交付的较严重的因素。经过后面深入的了解，发现浏览器在访问网站的过程中，有很多地方可以进行性能优化处理。
案例分析：
首先，我们先过直接写在页面上不会被浏览器缓存，所以不建议将页面上^Kimagesrc=”…”〉进行Base64转码，但是在样式文件中，很多图片是可以进行转码的，因为css样式文件是通过url地址引入的，会被IE缓存，所以css样式文件中的内容可以被一同缓存。
这里推荐一个在线进行Base64转码的网站：
。
Multipart支持
Multipart类型是HTTP/(RFC2616)协议支持的HTTP互联网媒体类型，所有的mulitipart类型共用一种通用定义。Multipart类型必须包含一个边界参数作为媒体类型值之一。根据RFC2616规范，一个Multipart类型的响应可以在消息体里包含一个或者多个entities，这个方案也可以帮助减少请求的数目，特别是动态请求的数目。
应用中包含很多静态和动态请求，例如基于组件的聚合应用(如IBMMashupsCenter)，则可以考虑在应用中使用Multipart方案。当然这需要额外的开发代价：
•客户端需要能够在一个请求里告知需要的请求数目和内容。
服务器端相应通过Multipart类型，把所需要的内容打包在一个响应内。
需要注意的是：
这会增加服务器端的负载，造成服务器端性能下降。
需要根据不同的应用来决定Multipart请求的封装粒度。
考虑终端浏览器端对于Multiplart请求的缓存支持。
页面廋身
网络带宽和页面大小的关系
在这些关系中页面大小和带宽的关系是最简单明了的，网络带宽决定了网路内每秒钟能传输的数据量的大小。同样大小的文件，在低带宽网络环境下的传输时间将大于高带宽的网络环境。所以：消耗在带宽上的时间=页面大小/网络带宽
通常我们减少页面大小有如下途径：
Gzip压缩文件内容
网络传输中的HTTP请求和应答时间可以通过前端机制得到显著改善。的确，终端用户的带宽、互联网提供者、与对等交换点的靠近程度等都不是网站开发者所能决定的。但是还有其他因素影响着响应时间。通过减小HTTP响应的大小可以节省HTTP响应时间。
从HTTP/，web客户端都默认支持HTTP请求中有Accept-Encoding文件头的压缩格式：
Accept-Encoding:gzip,deflate。如果web服务器在请求的文件头中检测到上面的代码，就会以客户端列出的方式压缩响应内容。Web服务器把压缩方式通过响应文件头中的Content-Encoding来返回给浏览器。
Gzip是目前最流行也是最有效的压缩方式。这是由GNU项目开发并通过RFC1952来标准化的。另外仅有的一个压缩格式是deflate，但是它的使用范围有限效果也稍稍逊色。
Gzip大概可以减少70%的响应规模。目前大约有90%通过浏览器传输的互联网交换支持gzip格式。如果你使用的是Apache,gzip模块配置和你的版本有关:,而A