今日大致阅读了一下《High Performance Web Sites》。本书的中文版是《高性能网站建立指南》。

本书另有对其中个别问题深化探求的进阶篇《Even Faster Web Sites》，中译《高性能网站建立进阶指南》。

作者引见上面的豆瓣链接中有，就不再照搬过来了。

这本书中给出了14条网站性能提升的准绳，每个准绳独立成章，配有示例。这些准绳大多数都十分适用，合适站点架构师、前端工程师。其中关于前端工程师的意义更大一些。

这次看的是原版。我关于Web开发较缺乏理论经历，加之看得匆忙，因而可能存在遗漏、表述不当之处，希望广阔网友不吝指正。

准绳1 减少HTTP恳求数

结构恳求、等候响应需求时间，因而恳求数量越少越好。减少恳求的总体思绪就是兼并资源，减少显现一个页面需求的文件数。

1. Image Map

经过设置标签的usemap属性与运用

2. CSS Sprite（CSS贴图整合/贴图拼合/贴图定位）

经过设置元素的background-position款式做到。普通用于界面图标。典型的能够参考TinyMCE编辑器上方的那些小按钮。多个小图本质是从一个统一的大图经过不同的偏移量裁剪而来，这样加载界面上的众多按钮实践上只需恳求一次（恳求大图一次），从而减少HTTP恳求数。

3. Inline Image（内联图片）

在的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）页面将比外联（运用 标签引入）页面加载更快（由于其较少的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。