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地址为缓存依据，经过直接写在页面上不会被浏览器缓存，所以不建议将页面上的<image src=”…” />进行Base64转码，但是在样式文件中，很多图片是可以进行转码的，因为css样式文件是通过url地址引入的，会被IE缓存，所以css样式文件中的内容可以被一同缓存。
这里推荐一个在线进行Base64转码的网站：wyvern/code/php/binary2base64。
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来说精简的风险更小。
      除消减外部的脚本和样式表文件外，<script>和<style>代码块也可以并且应该进行消减。即使你用Gzip压缩过脚本 和样式表，精简这些文件仍然可以节省5%以上的空间。由于JavaScript和CSS的功能和体积的增加，消减代码将会获得益处。
3. 服务器异步交互
         异步交互就是一个简单的多线程。在必要的时候应用可以不需要刷新整个页面来更新页面上的内容，对于用户而言完全是一个“无刷新”、“无阻塞”的过程，而在这个过程中，异步交互默默的在后台工作，而不是像传统的B/S应用那样必须是：用户请求刷新页面内容时必须提交HTTP请求，然后强制用户进入提交、等待、重新显示交互结果的过程。
这样交互过程，可以极大的减少页面与服务器之间的数据交互量，同时，因为页面没有刷新，css样式、js脚本等等外部引入文件不需要重新加载，虽然这些文件已经被缓存，但也省去了页面重新渲染的时间，好处多多 : )
4. 优化缓存策略
适当的设置缓存机制，通过浏览器来缓存静态资源或者部分动态资源，能有效的使用户在多
次访问应用时得到更快的页面响应。不一致的缓存机制会导致重复下载资源，并造成带宽资源的浪费以及成本的增加
∙ Cache-Control：这是缓存控制中最重要的一个配置项，所有的缓存实现（浏览器、代理程序）都必须遵循它的规则。
∙ Expires：指定在某一个时间点之后，该缓存项被认为失效。
∙ Last-Modified：Last-Modified 头信息通常被用作缓存验证符。简单来说，如果一个资源从 Last-Modified 时间点之后未被更新过，该资源的缓存内容将被认为仍然有效。
∙ Etag:ETag 是一个由服务器端生成的验证信息返回头信息，它在 HTTP 返回的头信息中，是一个经过编码的字符串信息。当第二次请求发生时，ETag 信息也被同时发送，用来判断该请求是否被修改，以确定是否需要重新发送完整的响应内容。
在服务器体系架构里，可以在不同的层面设置缓存控制头信息：
∙ 可以在应用里面对资源指定缓存控制信息。
∙ 如果部署了 HTTP 服务，可以在 HTTP 服务里面配置不同类型资源的缓存控制。如果部署了 Proxy 代理服务器，也可以在 Proxy 代理服务里配置缓存控制。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。