原则1 减少HTTP请求数
构造请求、等待响应需要时间，因此请求数量越少越好。减少请求的总体思路就是合并资源，减少显示一个页面需要的文件数。
1. Image Map
通过设置<img>标签的usemap属性与使用<map>标签可以在一幅图片上切分出多个区域，指向不同的链接。比起使用多幅图片分别构造链接减少了请求数。
2. CSS Sprite（CSS贴图整合/贴图拼合/贴图定位）
通过设置元素的background-position样式做到。一般用于界面图标。典型的可以参考TinyMCE编辑器上方的那些小按钮。多个小图实质是从一个统一的大图通过不同的偏移量裁剪而来，这样加载界面上的众多按钮实际上只要请求一次（请求大图一次），从而减少HTTP请求数。
3. Inline Image（内联图片）
在<img>的src中不指定外部图片文件的URL，而是直接将图片信息放入。例如src=”data:image/gif;base64,R0lGODlhDAAMAL...”某些特殊情况下有用（例如一个不大的图片仅在当前页面用到）。
原则2 利用多线路CDN
为你的站点提供多种线路（例如国内电信、联通、移动）、多个地理位置（北方、南方、西部）的访问，使得所有用户都能够快速访问。
原则3 利用HTTP Cache
给不频繁更新的资源（例如静态图）加较长的Expires头信息，这些资源一经缓存，未来很长时间都可以不再重复传输了。
原则4 使用Gzip压缩
使用Gzip压缩HTTP报文，减小体积，减少传输时间。
原则5 将样式表置于页面前部
先加载样式表，这样页面渲染得以较早开始，给用户页面加载较快的感觉。
原则6 将脚本置于页面尾部
原因同5，先处理页面显示，页面渲染较早完成，而脚本逻辑稍后执行，这样给用户页面加载较快的感觉。
原则7 避免使用CSS表达式
过于复杂的JavaScript脚本逻辑、DOM查找、选择操作将会降低页面处理效率。
原则8 将JavaScript与CSS作为外联资源
这似乎与原则1中的合并思想相悖，但其实不然：考虑每个页面都引入了一个公共的JavaScript资源（例如jQuery或是ExtJS这样的JavaScript库），单就一个页面的表现来看，内联（即将JavaScript嵌入HTML）页面将比外联（使用<script>标签引入）页面加载更快（因为其较少的HTTP请求数）。但如果有很多页面都引入了这个公共JavaScript资源，那么内联方案会造成重复传输（因为这个资源内嵌在每个页面中了，所以每次打开一个页面都要将这部分资源传输一遍，从而造成网络传输资源的浪费）。而将这种资源独立出来外联引用可以解决这个问题。
由于JavaScript和CSS相对稳定，我们可以对其对应的资源设置较长的失效期（参考原则3）。
原则9 减少DNS查找
作者给出的建议是：
1. 使用Keep-Alive保持连接
如果连接断开，那么下次连接又要执行DNS查找，即使对应的域名-IP映射已被缓存，查找也是要消耗一些时间的
2. 减少域名
每次请求新域名都需要进行通过DNS查找不同的域名，且DNS缓存无法发挥作用。因此应该尽量将站点组织在一个统一域名下，避免使用过多子域名
原则10 压缩你的JavaScript
使用JS压缩工具压缩你的JavaScript吧，很有效哦。看看jQuery的两个不同的发行版本就知道区别了：
http://code.jquery.com/jquery-1.6.2.js 阅读版jQuery代码，230KB
http://code.jquery.com/jquery-1.6.2.min.js 压缩版jQuery代码（用于实际部署），89.4KB
原则11 尽量避免重定向
一次重定向意味着在你真正访问到想要看到的页面前加入了一轮额外的HTTP请求（客户端发起HTTP请求→HTTP服务器返回重定向响应→客户端对新URL发起请求→HTTP服务器返回内容，下划线部分为额外的请求），因此消耗更多的时间（也就给人反应更慢的感觉）。因此除非必要，不要随意使用重定向。几个“必要”的情况：
1. 避免URL失效
旧站点迁移后，为了避免旧的URL失效，通常将对旧URL的请求重定向至新系统的对应地址。
2. URL美化
在可读性好的URL与实际资源URL之间转换，例如对于Google Toolbar，用户记得住http://toolbar.google.com这个对人类富有语义的地址，却很难记住http://www.google.com/tools/firefox/toolbar/FT3/intl/en/index.html这个真正的资源地址。因此有必要保留前者，并且将对前者的请求重定向至后者。
原则12 移除重复的脚本
不要在一个页面中重复引入相同的脚本。例如脚本B和C都依赖于A，那么在使用了B和C的页面中就有可能存在对A的重复引用。解决方法，对于简单的站点手动检查依赖性，消去重复引入；对于复杂的站点则需要构建自己的依赖管理/版本控制机制。
原则13 小心处理ETag
ETag是除Last-Modified之外的另一种HTTP Cache手段。通过hash的办法辨识资源是否被修改。但ETag存在一些问题，例如：
1. 不一致：不同Web服务器（Apache, IIS等）定义的ETag格式不同
2. ETag的计算是不稳定的（由于考虑过多因素），例如：
1) 相同资源在不同服务器上计算出来的ETag不一样，而大型Web应用通常由不止一台服务器提供服务，这就导致客户端在服务器A缓存好的资源明明仍然有效，而在下次请求B时由于ETag不同而被认定为失效，导致相同资源的重复传输。
2) 资源不变，而由于一些其他因素的变化，例如配置文件更改，导致ETag变化。直接后果是系统更新后客户端大规模发生Cache失效，导致传输量大增，站点性能下降。
作者给出的建议是：要么根据你的应用特点改进已有的ETag计算方法，要么干脆就不用ETag，而改用最简单的Last-Modified.
原则14 在Ajax中利用HTTP Cache
Ajax是异步请求，异步请求不会阻塞你现在的操作，而且当请求完成时，你马上就可以看到结果。但异步不代表能够瞬时完成，也不代表能够容忍它花无限多的时间完成。因此对于Ajax请求的性能也需要重视。有很多Ajax请求访问的是一些相对稳定的资源，因此别忘了对Ajax请求利用好HTTP Cache机制，具体参见原则3、13.
