从YUI14看构建高性能网站

读过《高性能网站建设指南》（就是有只狗的那本书）这本书的朋友都知道YUI14条，它一直都被很多人奉为网站优化的黄金法则。今天就来做点读书笔记，整理一下思路吧。

对于YUI14条就认为是构建高性能的网站法则未免以偏概全，特别我发现身边好多人特别对权威说的话从不怀疑。然而，我以为YUI14条仅仅针对的是加载速度的提升作的建议，所有几乎是围绕着改善HTTP请求而设的，由此我想引申一下自己的看法。

一、减少HTTP请求数量

这是最好的方法，也是最直接的方法，特别是在下载小文件（10K左右）的情况下尤其明显，请不要忽略TCP三次握手时间，在下载小文件的情况下，其影响非常大。

1.采用CSS Sprite ，简单点来说就是把多个小图合并成大图，然后再通过CSS背景定位显示图像，一般用来减少显示UI的小图片，并且把多张小图片合并在一起能够减少整体体积，但是要求技术比较高。

2.对于SPA应用（单页面应用），由于较少涉及整体页面的跳转，并且CSS的样式显示不像JS具有依赖关系，所以可以进行合并样式表后一次加载，甚至是直接采用内敛方式也可以（但这个方式不便于维护）。其实YUI中所提到把层叠样式表放到页头，把脚本放到页脚是从用户体验的角度去说，同样，我建议构建高性能网站遵循的体验原则是宁愿一开始加载10s，也不要每次操作都加载1s。

3.采用本地缓存，这个功能通过两个途径可以实现，第一是设置文件过期时间，较少对静态文件的重复下载；第二采用HTML5的本地存储，减少对服务器的重复查询，但是采用本地存储需要浏览器的支持，如果你已经抛弃了IE6,IE7用户，那么请大胆使用。

二、减小HTTP请求体积

在没办法削减请求数量的时候，那么就只能压缩，优化，再压缩。

1.压缩JS脚本，CSS样式表，这个不用多说了，用工具去压缩吧。个人认为压缩效果从百分比上看是十分可观的，但是从大小变化上就不如少一张100K+的图片，当然如果你是做亿级访问量的Web那么就能让你节省很多的带宽。

2.压缩图片，关于这个话题我并不是专业，但是明显可以知道图片压缩的价值大于脚本压缩。一般采用方法是用PNG代替GIF图标，或者你可以选择Geek一点，对特定业务场景对图片有特殊处理。例如QQ秀的优化，我们可以把人物遮住的背景图片挖空，减少图片的体积（heard from webrebulid）。

3.使用PNG代替GIF，根据统计，采用PNG格式的icon小图体积要比GIF的小。不过，你还是考虑IE6用户的话，那么你可能要给PNG挂上个滤镜，其中的开销反而会得不偿失。

4.采用GZIP，作为一名前端人员，这个东西目前我只在构建服务器的时候看了一下，希望可以有大牛告诉我如何从前端层面启用GZIP，抑或服务器响应头标明GZIP即自动开启该压缩功能。

5.采用AJAX，对了我们很多人都会使用这个很炫的方法，但是我们有没有想过除了它能带给你无刷新获取数据提高用户体验之外，还有什么优点呢？它能减少加载内容的体积！当然你可以仅仅回调数据，或者回调已经装饰好的数据，前者需要多一点修饰代码，哪个更好看你如何去衡量，作为一名前端开发人员，我想大概也会偏向前者吧。

6.架构优势，有人会疑问架构优势有什么关系？这个问题其实就相当于问采用jQuery有什么好处，它可以加快我们的开发效率之外，能够让我们写更少的代码，就像它的宣言（write less do more）。当然本身框架也是有体积的，这条建议的前提是，你是在构建一个依赖于大量脚本的站点。（根据之前看回来的消息，Gmail的代码量达到50W）

三、加快HTTP请求的速度

1.物理上增加带宽。（我觉得这条是不应该说的，好吧，你不要管这条）

2.采用CDN（内容分发网络），非常有用的方法，既可以减少对本站服务器的HTTP请求，又可以减轻带宽的占用，简而言之就是减轻对主服务器的负载，正如我们看煎蛋（http://jandan.net/）采用wordpress，它使用了CDN图床。

3.少用POST请求，我发觉身边的很多的同学都很喜欢用POST而不是GET，因为他们觉得这样可以保密。那么我告诉大家，其实两种都不会起保密的作用，只是get的信息暴露在请求头（所以你看到URL上面的数据会认为它是危险的），post的信息暴露在请求体，两者都是非加密的，但是采用Get请求明显可以向服务器少发很多资源。所以要合理采用

4.网页静态化。把动态页的计算结果缓存起来，要比每次请求都重新作计算显然要明智得多。当然，如果你对站点的实时性有很高要求，那么这条建议还是不用为上，因为静态文件的生成速度可能赶不上你获取数据的速度。

好吧，就先说到这儿吧，有机会再谈。　　:-)