如果连接断开，那么下次连接又要执行DNS查找，即使对应的域名-IP映射已被缓存，查找也是要消耗一些时间的
2. 减少域名
每次请求新域名都需要进行通过DNS查找不同的域名，且DNS缓存无法发挥作用。因此应该尽量将站点组织在一个统一域名下，避免使用过多子域名
原则10 压缩你的JavaScript
使用JS压缩工具压缩你的JavaScript吧，很有效哦。看看jQuery的两个不同的发行版本就知道区别了：
http://code.jquery.com/jquery-1.6.2.js 阅读版jQuery代码，230KBhttp://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.
原文：http://www.cnblogs.com/mdyang/archive/2011/07/12/high-performance-web-sites.html
评论