性能优化指南
性能优化指南(一些资料的整理总结)
-
Http
80%的响应时间花在下载网页内容(images, stylesheets, javascripts, scripts, flash等)。减少请求次数是缩短响应时间的关键!可以通过简化页面设计来减少请求次数,但页面内容较多可以采用以下技巧。
-
Combined Files:合并文件,如将JS或CSS捆绑成同一个文件,以此来减少文件的下载次数
-
CSS Sprites:又名雪碧图,将多张图片合并成一张图片,减少图片请求次数,通过background-position来控制图片位置
-
Image Maps:合并多个图片到一个图片,一般用于如导航条。由于定义坐标的枯燥和易错,一般不推荐
-
Inline Images:使用data:url scheme来內连图片,可通过base64编码的字符串将图片内嵌到网页文本中
base64转码后图片尺寸会放大约1/3,可以放在文档文件中传输,经过Gzip可以压缩很多,所以整体有优化效果
大图片不建议这么处理,因为浏览器渲染引擎渲染base64的图片会消耗CPU计算量
-
-
Server
-
添加Expires或Cache-Control报文头使回复可以被客户端缓存
-
对静态组件:通过设置Expires头部来实现“永不过期”策略
-
对动态组件:用合适的Cache-Control头部来帮助浏览器进行有条件请求
-
页面越来越丰富,意味着更多脚本,样式,图片等等。第一次访问的用户可能需要发出多个请求,但使用Expires可以让这些组件被缓存。这避免了访问子页面时没必要的http请求。Expires一般用在图片上,但应该用在所有的组件上。
注意,如果你设置了Expires头部,当组件更新后,你必须更改文件名
-
-
Gzip压缩传输
Gzip通常可以减少70%的响应大小。尽可能的去Gzip更多的文本类型文件。如:html,脚本,样式,xml和json等等都应该被gzip
值得注意的是图片,pdf等等不应该被gzip,因为它们本身已被压缩过,gzip它们只是浪费cpu,甚至增加文件大小
-
配置ETags
实体标记(Entity tags,ETag)是服务器和浏览器之间判断浏览器缓存中某个组件是否匹配服务器端原组件的一种机制。 实体就是组件:图片,脚本,样式等等。ETag被当作验证实体的比最后更改日期更高效的机制。
ETag的问题是它们被构造来使它们对特定的运行这个网站的服务器唯一。 浏览器从一个服务器获取组件,之后向另一个服务器验证,ETag将不匹配。然而服务器集群是处理请求的通用解决方案。 如果不能解决多服务器间的ETag匹配问题,那么删除ETag可能更好。
-
尽量使用GET Ajax请求
浏览器在实现XMLHttpRequest POST的时候分成两步,先发header,然后发送数据。而GET却可以用一个TCP报文完成请求。另外GET从语义上来讲是去服务器取数据,而POST则是向服务器发送数据,所以我们使用Ajax请求数据的时候尽量通过GET来完成。
关于GET和POST的详细对比可以查看这里
-
避免空src的图片
-
-
Cookie
-
减少Cookie开销
http cookie的使用有多种原因,比如授权和个性化。cookie的信息通过http头部在浏览器和服务器端交换。尽可能减小cookie的大小来降低响应时间。
-
消除不必要的cookie。
-
尽可能减小cookie的大小来降低响应时间。
-
注意设置cookie到合适的域名级别,则其它子域名不会被影响。
-
正确设置Expires日期。早一点的Expires日期或者没有会尽早删除cookie,优化响应时间。
-
-
用没有cookie的域名提供组件。
当浏览器请求静态图片并把cookie一起发送到服务器时,cookie此时对服务器没什么用处。所以这些cookie只是增加了网络流量。所以你应该保证静态组件的请求是没有cookie的。可以创建一个子域名来托管所有静态组件。
比如,你域名是www.example.org,可以把静态组件托管在static.example.org。不过,你如果把cookie设置在顶级域名example.org下,这些cookie仍然会被传给static.example.org。这种情况下,启用一个全新的域名来托管静态组件。
另外一个用没有cookie的域名提供组件的好处是,某些代理可能会阻止缓存待cookie的静态组件请求。
-
-
JavaScript
-
把脚本放到底部
脚本引起的问题是它们阻塞了并行下载。HTTP1.1规范建议浏览器每个域名下不要一次下载超过2个组件。如果你的图片分散在不同服务器,那么你能并行下载多个图片。但当脚本在下载,浏览器不会再下载其它组件,即使在不同域名下。
有些情况下把脚本移动到底部并不简单。比如,脚本中用了document.write来插入内容,它就不能被移动到底部。另外有可能有作用域问题。但大多数情况,有方法可以解决这些问题。
一个替代建议是使用异步脚本。defer属性表明脚本不包含document.write,是提示浏览器继续渲染的线索。不幸的是,Firefox不支持。如果脚本能异步,那么也就可以移动到底部。
-
压缩JS和CSS
压缩就是删除代码中不必要的字符来减小文件大小,从而提高加载速度。当代码压缩时,注释删除,不需要的空格(空白,换行,tab)也被删除。
-
最小化DOM访问
用JS访问DOM元素是缓慢的,所以为了响应更好的页面,你应该:
-
缓存访问过的元素的引用
-
在DOM树外更新节点,然后添加到DOM树
-
避免用JS实现固定布局
-
-
-
CSS
-
CSS文件写在头部进行引用
-
避免在文档内内联样式和脚本
-
避免滥用web字体
-
避免CSS表达式
-
用<link>代替@import
-
避免使用(IE)过滤器
-
-
Image
-
优化图片
-
检查gif图片的调色板大小是否匹配图片颜色数。
-
可以把gif转成png看看有没有变小。除了动画,gif一般可以转成png8。
-
运行pngcrush或其它工具压缩png。
-
运行jpegtran或其它工具压缩jpeg。
-
-
优化CSS雪碧图
-
把图片横向合并而不是纵向,横向更小。
-
把颜色近似的图片合并到一张雪碧图,这样可以让颜色数更少,如果低于256就可以用png8
-
"Be mobile-friendly"并且合并时图片间的间距不要太大。这对图片大小影响不是太大,但客户端解压时需要的内存更少。100×100是10000个像素,1000×1000是1000000个像素。
-
-
不要在html中缩放图片
不要通过图片缩放来适应页面,如果你需要小图片,就直接使用小图片吧。
-
favicon.ico小且缓存
favicon.ico是在你服务器根路径的图片。蛋疼的是即使你不关心它,浏览器仍然会请求它。所以最好不要响应404。另外由于在同一服务器,每次请求favicon.ico时也会带上cookie。这个图片还会影响下载顺序,比如在IE,如果你在onload时下载额外的组件,fcvicon会在这些组件之前被下载。
怎么减轻favicon.ico的缺点?
-
小,最好1K以下
-
设置Expires头部。也许可以安全地设置为几个月
-
-
-
Mobile
-
保持组件小于25K
这个限制与iPhone不缓存大于25K的组件相关。注意,这是非压缩(uncompressed)的文件大小。在这里minification(压缩,不要与compress混淆)很重要,因为gzip无法满足(iPhone)。
-
打包组件到一个多部父文档
打包组件到一个多部父文档类似于带附件的邮件。它帮助你在一个http请求中获取多个组件,但注意,iPhone不支持。
-