web系统性能优化
WEB站点性能优化
由于较少的接触WAP站点的建设，缺乏类似站点的建设经验，导致后期的性能问题成了影响项目交付的较严重的因素。
经过后面深入的了解，发现浏览器在访问网站的过程中，有很多地方可以进行性能优化处理。案例分析：
首先，我们先来了解一下客户端(这里指终端浏览器)访问服务器的全过程。
以火狐3.6.8浏览器为例(图例来自火狐浏览插件firebug截图)
从上图可以看出，该页面前后一共向后台发送了6次请求，即建立6次连接。
●过程一：第1次请求，url地址请求服务器，获得相应的页面html，该次请求需要服务器相
应的业务逻辑处理然后生成页面，花费的时间稍长。
●过程二：第2、3次请求，终端浏览器接收到请求的html页面后，需要请求页面引入的外部
资源(如css样式,js脚本,图片等)，此时请求过程是并行连接。
●过程三：第4、5、6次请求，终端浏览器接收到css样式资源后，需要为css中引入的其他外
部资源(图片较为常见)再次发送请求，所有的图片请求也是并行连接，与此同时也会进行页面的渲染工作。
另外，过程二、过程三中提到的并行连接，在各种不同浏览器中体现出来的能力也不一样。
下图显示了每个支持当前的浏览器为HTTP/1.1中以及HTTP/1.0的服务器最大连接数。
简化的浏览器响应时间的计算模型：
终端用户响应时间= 页面下载时间+ 服务器响应时间+ 浏览器处理及渲染时间
页面下载时间= 页面大小/ 网络带宽+ （网络延迟×HTTP 请求数）/ 并发度
所以如果我们可以通过监听互联网应用的网络传输行为得到页面大小、HTTP 请求数、并发度、服务器响应时间和浏览器处理及渲染时间，那么我们就可以推测这个应用在任意网络环境下的终端用户响应时间
优化思路
从上面公式中可以看出，网络带宽、网络延迟由网络环境决定，是系统不可控的，并发度是终端浏览器本身具备的能力，也是系统不可控的。余下的公式参数页面尺寸，HTTP请求数则是我们需要找寻的突破点，我们可以从如下几个方向着手。
1. 减少连接次数
终端浏览器响应的时间中，有80%用于下载各项内容。这部分时间包括下载页面中的图像、样式表、脚本、Flash等。通过减少页面中的元素可以减少HTTP请求的次数。这是提高网页速度的关键步骤。
合并文件
是通过把所有的脚本放到一个文件中来减少HTTP请求的方法，如可以简单地把所有的CSS 文件都放入一个样式表中。当脚本或者样式表在不同页面中使用时需要做不同的修改，这可能会相对麻烦点，但即便如此也要把这个方法作为改善页面性能的重要一步。
CSS Sprites
是减少图像请求的有效方法。把所有的背景图像都放到一个图片文件中，然后通过CSS的background-image和background-position属性来显示图片的不同部分；
内联图像
是使用data:URL scheme的方法把图像数据加载页面中。这可能会增加页面的大小。把内联图像放到样式表（可缓存）中可以减少HTTP请求同时又避免增加页面文件的大小。但是内联图像现在还没有得到主流浏览器的支持。
推荐使用Base64转码内联：
将图片Base64转码后直接写在页面上，也可以节省掉该图片的连接，但基于IE缓存策略是以url地址为缓存依据，经过直接写在页面上不会被浏览器缓存，所以不建议将页面上的
这里推荐一个在线进行Base64转码的网站：
Multipart支持
Multipart 类型是HTTP/1.1(RFC2616) 协议支持的HTTP 互联网媒体类型，所有的mulitipart 类型共用一种通用定义。Multipart 类型必须包含一个边界参数作为媒体类型值之一。根据RFC2616 规范，一个Multipart 类型的响应可以在消息体里包含一个或者多个entities，这个方案也可以帮助减少请求的数目，特别是动态请求的数目。
应用中包含很多静态和动态请求，例如基于组件的聚合应用（如IBM Mashups Center)，则可以考虑在应用中使用Multipart 方案。当然这需要额外的开发代价：
?客户端需要能够在一个请求里告知需要的请求数目和内容。
?服务器端相应通过Multipart 类型，把所需要的内容打包在一个响应内。
需要注意的是：
?这会增加服务器端的负载，造成服务器端性能下降。
?需要根据不同的应用来决定Multipart 请求的封装粒度。
?考虑终端浏览器端对于Multiplart 请求的缓存支持。
2. 页面廋身
网络带宽和页面大小的关系
在这些关系中页面大小和带宽的关系是最简单明了的，网络带宽决定了网路内每秒钟能传输的数据量的大小。同样大小的文件，在低带宽网络环境下的传输时间将大于高带宽的网络环境。所以：消耗在带宽上的时间= 页面大小/ 网络带宽
通常我们减少页面大小有如下途径：
Gzip压缩文件内容
网络传输中的HTTP请求和应答时间可以通过前端机制得到显著改善。的确，终端用户的带宽、互联网提供者、与对等交换点的靠近程度等都不是网站开发者所能决定的。但是还有其他因素影响着响应时间。通过减小HTTP响应的大小可以节省HTTP响应时间。
从HTTP/1.1开始，web客户端都默认支持HTTP请求中有Accept-Encoding文件头的压缩格式： Accept-Encoding: gzip, deflate。如果web服务器在请求的文件头中检测到上面的代码，就会以客户端列出的方式压缩响应内容。Web服务器把压缩方式通过响应文件头中的Content-Encoding 来返回给浏览器。
Gzip是目前最流行也是最有效的压缩方式。这是由GNU项目开发并通过RFC 1952来标准化的。另外仅有的一个压缩格式是deflate，但是它的使用范围有限效果也稍稍逊色。
Gzip大概可以减少70%的响应规模。目前大约有90%通过浏览器传输的互联网交换支持gzip 格式。如果你使用的是Apache，gzip模块配置和你的版本有关：Apache 1.3使用mod_zip，而Apache 2.x使用moflate。
浏览器和代理都会存在这样的问题：浏览器期望收到的和实际接收到的内容会存在不匹配的现象。幸好，这种特殊情况随着旧式浏览器使用量的减少在减少。Apache模块会通过自动添加适当的Vary响应文件头来避免这种状况的出现。
服务器根据文件类型来选择需要进行gzip压缩的文件，但是这过于限制了可压缩的文件。大多数web服务器会压缩HTML文档。对脚本和样式表进行压缩同样也是值得做的事情，但是很多web服务器都没有这个功能。实际上，压缩任何一个文本类型的响应，包括XML和JSON，都值得的。图像和PDF文件由于已经压缩过了所以不能再进行gzip压缩。如果试图gizp压缩这些文件的话不但会浪费CPU资源还会增加文件的大小。
图片压缩
?你可以检查一下你的GIF图片中图像颜色的数量是否和调色板规格一致。使用imagemagick中下面的命令行很容易检查：
identify -verbose image.gif
如果你发现图片中只用到了4种颜色，而在调色板的中显示的256色的颜色槽，那么这张图片就还有压缩的空间。
?尝试把GIF格式转换成PNG格式。大多数情况下是可以压缩的。由于浏览器支持有限，设计者们往往不太乐意使用PNG格式的图片，不过这都是过去的事情了。现在只有一个问题就是在真彩PNG格式中的alpha通道半透明问题，不过同样的，GIF也不是真彩格式也不支持半透明。因此GIF能做到的，PNG（PNG8）同样也能做到（除了动画）。下
面这条简单的命令可以安全地把GIF格式转换为PNG格式：
convert image.gif image.png
?在所有的PNG图片上运行pngcrush（或者其它PNG优化工具）。例如：
pngcrush image.png -rem alla -reduce -brute result.png
?在所有的JPEG图片上运行jpegtran。这个工具可以对图片中的出现的锯齿等做无损操作，同时它还可以用于优化和清除图片中的注释以及其它无用信息（如EXIF信息）：
jpegtran -copy none -optimize -perfect src.jpg dest.jpg
削减JavaScript和CSS
精简是指从去除代码不必要的字符减少文件大小从而节省下载时间。消减代码时，所有的注释、不需要的空白字符（空格、换行、tab缩进）等都要去掉。在JavaScript中，由于需要下载的文件体积变小了从而节省了响应时间。精简JavaScript中目前用到的最广泛的两个工具是JSMin 和YUI Compressor。YUI Compressor还可用于精简CSS。
混淆是另外一种可用于源代码优化的方法。这种方法要比精简复杂一些并且在混淆的过程更易产生问题。精简也可以缩小原来代码体积的21%，而混淆可以达到25%。尽管混淆法可以更好地缩减代码，但是对于JavaScript来说精简的风险更小。
除消减外部的脚本和样式表文件外，