转载一篇实用文章，干活多多

今日大体浏览了一下《High Performance Web Sites》。本书的中文版是《高性能网站建设指南》。本书另有对其中个别问题深刻探究的进阶篇《Even Faster Web Sites》，中译《高性能网站建设进阶指南》。

　　这本书中给出了14条网站性能提高的原则，每一个原则独立成章，配有示例。这些原则大多数都很是实用，适合站点架构师、前端工程师。其中对于前端工程师的意义更大一些。

　　此次看的是原版。我对于Web开发较缺少实践经验，加之看得匆忙，所以可能存在遗漏、表述不当之处，但愿广大网友不吝指正。

　　原则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机制，具体参见原则三、13.