web性能优化_(转载文)
转载自:http://www.cnblogs.com/50614090/archive/2011/08/19/2145620.html
第一章 打开网站慢现状分
在公司访问部署在IDC机房的VIP网站时会感觉很慢。是什么原因造成的?为了缩短页面的响应时间,改进我们的用户体验,我们需要知道用户的时间花在等待什么东西上。
可以跟踪一下我们的登录页面,如下图所示
从上图我们可以分析知道,HTML文档只占了总响应时间的20%,其它80%响应时间用来下载JS、CSS、图片等组件。所以WEB前端有很大的优化空间,我们将从WEB的前端优化、后端优化两方面综合考虑给出WEB的性能优化方案。
第二章 WEB前台的优化规则
一、尽量减少 HTTP 请求
有几种常见的方法能切实减少 HTTP 请求:
1、 合并脚本跟样式文件,如可以把多个 CSS 文件合成一个,把多个 JS 文件合成一个。
2、 CSS Sprites 利用 CSS background 相关元素进行背景图绝对定位,把多个图片合成一个图片。
二、使用浏览器缓存
在用户浏览网站的不同页面时,很多内容是重复的,比如相同的JS、CSS、图片等。如果我们能够建议甚至强制浏览器在本地缓存这些文件,将大大降低页面产生的流量,从而降低页面载入时间。
根据服务器端的响应header,一个文件对浏览器而言,有几级不同的缓存状态。
1、服务器端告诉浏览器不要缓存此文件,每次都到服务器上更新文件。
2、服务器端没有给浏览器任何指示。
3、在上次传输中,服务器给浏览器发送了Last-Modified或Etag数据,再次浏览时浏览器将提交这些数据到服务器,验证本地版本是否最新的,如果为最新的则服务器返回304代码,告诉浏览器直接使用本地版本,否则下载新版本。一般来说,有且只有静态文件,服务器端才会给出这些数据。
4、服务器强制要求浏览器缓存文件,并设置了过期时间。在缓存未到期之前,浏览器将直接使用本地缓存文件,不会与服务器端产生任何通信。
我们要做的是尽量强制浏览器到第四种状态,特别是对于JS、CSS、图片等变动较少的文件。
三、使用压缩组件
IE和Firefox浏览器都支持客户端GZIP,传输之前,先使用GZIP压缩再传输给客户端,客户端接收之后由浏览器解压,这样虽然稍微占用了一些服务器和客户端的CPU,但是换来的是更高的带宽利用率。对于纯文本来讲,压缩率是相当可观的。如果每个用户节约50%的带宽,那么租用来的那点带宽就可以服务多一倍的客户,并且缩短了数据的传输时间。
四、图片、JS的预载入
预载入图像最简单的方法是在 JavaScript 中实例化一个新 Image() 对象,然后将需要载入的图像的 URL 作为参数传入。
function preLoadImg(url) {
var img = new Image();
img.src = url;
}
可以在登录页面预载入JS和图片
五、将脚本放在底部
脚本放在顶部带来的问题,
1、 使用脚本时,对于位于脚本以下的内容,逐步呈现将被阻塞
2、 在下载脚本时会阻塞并行下载
放在底部可能会出现JS错误问题,当脚本没加载进来,用户就触发脚本事件。
要综合考虑情况。
六、将样式文件放在页面顶部
如果样式表任在加载,构建呈现树就是一种浪费,样式文件放在页面底部可能会出现两种情况:
1、 白屏
2、 无样式内容的闪烁
七、使用外部的JS和CSS
将内联的JS和CSS做成外部的JS、CSS。减少重复下载内联的JS和CSS。
八、切分组件到多个域
主要的目的是提高页面组件并行下载能力。但不要跨太多域名,建议采用2个子域名。
九、精简JS
可以做到两个级别
1、精简:从代码中移除不必要的字符以减少其大小,
2、混淆:在精简的同时,还会改写代码,函数、变量名被转换成更短的字符串
可以使用ShrinkSafe来精简JS http://shrinksafe.dojotoolkit.org/
十、精简CSS
从代码中移除不必要的字符以减少其大小,
可以使用CSS Compressor http://www.cssdrive.com/index.php/main/csscompressor /
十一、 精简图片、Flash
对大图片、Flash,要在效果和大小之间做出平衡。
第三章 程序的优化
第四章 数据库的优化
附录A 页面请求分析
从输入URL到页面呈现需要下面5个步骤
1. 输入URL地址或者点击URL的一个链接
2. 浏览器根据URL地址,结合DNS,解析出URL对应的IP地址
3. 发送HTTP请求
4. 开始连接请求的服务器并且请求相关的内容
5. 浏览器解析从服务器端返回的内容,并且把页面显现出来
上面基本上就是一个页面从请求到实现的基本过程,下面我们将剖析这个过程。
当输入URL之后,浏览器就要知道这个URL对应的IP是什么,只有知道了IP地址,浏览器才能准备的把请求发送到指定的服务器的具体IP和端口号上面。浏览器的DNS解析器负责把URL解析为正确的IP地址。这个解析的工作是要花时间的,而且这个解析的时间段内,浏览器不是能从服务器那里下载到任何的东西的。浏览器和操纵系统提供了DNS解析缓存支持。
当获得了IP地址之后,那么浏览器就向服务器发送HTTP的请求,过程如下:
1.浏览器通过发送一个TCP的包,要求服务器打开连接
2.服务器也通过发送一个包来应答客户端的浏览器,告诉浏览器连接开了。
3.浏览器发送一个HTTP的GET请求,这个请求包含了很多的东西了,例如我们常见的cookie和其他的head头信息。
这样,一个请求就算是发过去了。
请求发送去之后,之后就是服务器的事情了,服务器端的程序把最后的结果发送到客户端。
其实首先到达浏览器的就是html的那些文档,所谓的html的文档,就是纯粹的html代码,不包含什么图片,脚本,CSS等的。也就是页面的html结构。因为此时返回的只是页面的html结构。这个html文档的发送到浏览器的时间是很短的,一般是占整个响应时间的10%左右。
这样之后,那么页面的基本的骨架就在浏览器中了,下一步就是浏览器解析页面的过程,也就是一步步从上到下的解析html的骨架了。
如果此时在html文档中,遇到了img标签,那么浏览器就会发送HTTP请求到这个img响应的URL地址去获取图片,然后呈现出来。如果在html文档中有很多的图片,flash,那么浏览器就会一个个的请求,然后呈现,如果每个图片都要请求,那么就要进行之前说的那些步骤:解析url,打开tcp连接等等。打开连接也是要消耗资源的,就像我们在进行数据库访问一样,我们也是尽可能的少开数据库连接,多用连接池中的连接。道理一样,tcp连接也是可以重用的。http1.1提出了持久连接(persistent connection)的概念,也就是说同一条 HTTP 连接,可以同时处理多个请求,减少tcp连接。
当页面的html骨架载入了之后,浏览器就开始解析页面中标签,从上到下开始解析。
首先是head标签的解析,如果发现在head中有要引用的JS脚本,那么浏览器此时就开始请求脚本,此时整个页面的解析过程就停了下来,一直到JS请求完毕。之后页面接着向下解析,如解析body标签,如果在body中有img标签,那么浏览器就会请求img的src对应的资源,如果有多个img标签,那么浏览器就一个个的解析,解析不会像JS那样等待的,会并发的下载。