准则（概述）
- 减少 HTTP 请求
- 使用CDN加速
- 避免空的src或href属性值
- 增加过期头
- 启GZIP压缩
- 把css文件放到头部
- 把javascript放到尾部
- 避免使用css表达式
- 删除不使用的css语句
- 对javascript、css代码进行压缩
- 减少重绘
减少HTTP请求
减少HTTP请求是上面性能准则中最为显著的一条，我们可以分为三个主要方面来讨论
- 使用并行连接
开发人员往往只考虑服务器端对性能的影响却疏忽了浏览器端的限制，比如有多少资源可以在同一时间加载。HTTP1.1协议明确的限制了单个用户在同一时间不能保持两个以上的连接，但是，现代浏览器大部分都突破了这个限制，很多浏览器可以支持四个甚至六个并行的连接。同样的，你也可以将资源文件散列到不同的域名下面，这种做法充分的利用了浏览器并发，所以可以提高加载效率，但是由于DNS的查询有耗时，太多的域名解析又会使性能降低。 - 合并资源文件
并行链接的讨论得出一个结论，大一些的文件比小一些的文件好，虽然说这个说法听起来有些别扭，但是在现今的网络环境里，这个说法可以得到证实（体积大的文件比多个小文件加载快）。此外每个HTTP请求在时间上和带宽上至少会产生一些开销，如果可以合并资源，减少HTTP请求，会提升一定的性能。 - 使用图片精灵（css sprite）
这个名词应该比较熟悉和常用，它的意思就是把几张图片合并成一张。这是一种有效减少HTTP请求的方法，在使用图片的时候你只需要使用一些css的定位来决定这个图片的位置即可。当我们使用其中的一个图标时，其他的图片也会被缓存（不需要再次请求）如果有100个图标则可以减少99次HTTP请求。
使用CDN加速（内容分发系统）
CDN是一个拥有很多服务器、经过策略性部署的、可以覆盖全球的网络系统，当用户访问一个比较大的网站时，CDN会从最近的一个节点为用户提供服务。但是动态数据的处理最好放在集中的服务器中，因为跨地域同步数据库是一个令开发者头痛的问题，所有大多数互联网公司都把购买、登陆等数据相关的事物放到一个地方处理。另外，CDN服务是很贵的，如果网站的流量值得去付出这么多钱，它无疑会给性能带来提升。
避免空的src和href属性
我们使用javascript给空的src赋值时，javascript放在文档的最后，此时虽然src是空的仍然会发出一个HTTP请求。当我们点击一个空的href属性的链接时，同样会发出一个HTTP请求，虽然这个HTTP请求不会有影响加载时间但是会给服务端造成一定的流量浪费。我们可以创建一个带有描述性信息的很href属性，并阻止这次HTTP请求
<a href="#SometingDescriptive" id="TriggerName">TriggerName</a> <script type="text/javascript"> $("#TriggerName").click(function (e) { e.prventDefaulet(); // 取消默认行为 ... }); </script>
另外，空的src和href也是会产生报错的
增加过期头
增加了过期头之后浏览器便会缓存这些文件，当用户第二次访问这个网站的时候就不会再像服务端请求这个文件。关于缓存的详细介绍可以点这里
启用GZIP压缩
HTTP协议1.1引入了Accept-Encoding这个功能（表明HTTP请求的内容是压缩过的），GZIP就是其中的一种压缩方式，它是现在压缩比率最高的，据雅虎的统计它减小了大约70%的响应大小。它不仅仅会减小文件传输时间，同时也节省了带宽。
把css放在头部
浏览器并不会等全部HTML解析完成之后才渲染元素，而是同时进行，把css放到前面就会保证先渲染的那一部分元素的显示样式是正确的，这么写在性能方面也有很大的意义，你绝不希望引起大量的浏览器重绘。如果你的样式文件放到页面的底部，那么浏览器就会等所有文件都加载完才会绘制页面，那么用户很有可能盯着白屏一长段时间，
把javascript放在尾部
脚本会阻止并行加载（link支持最大限度的并行加载），也就是说，当浏览器加载一个脚本的时候时，它不会加载其他文件。如果脚本在头部那他会阻止页面的渲染。我们可以用script标签上的DRFFER属性通知浏览器去异步的加载其他文件，但是这么做会出现两个问题。
- 不是所有浏览器都认识这个属性
- 用了DEFFER属性的脚本不可以使用document.write()
避免使用css表达式
- 只有部分浏览器支持CSS表达式（IE5、6、7）
- 在打包压缩后CSS表达式会比正常的CSS长得多
- 执行频率高得多（往往当用户移动鼠标或滚动页面时它就会执行）
减少页面的回流与重绘
关于这个问题可以去我博客园的 博客 来查看。