昨天完整的读了一遍《高性能网站建设指南》，收获颇丰。正如作者序言里说的，拿到这本书的你是幸运的，但是更重要的是，你的网站的用户很幸运，：）
书的作者是YUI(Yahoo! User Interface)的一名核心开发人员，而书的内容是将他们在网站前端优化的14条原则逐一分享。
书很薄，适合我这种懒人，可以一天就读完，：） 不过书的内容简洁明了，很有操作性，道理也讲得明白，喜欢这种书的风格。
下面把这14条原则简单说一下，以做备忘。
规则1，减少HTTP请求
这是最重要的原则，如果14条规则里只能选一条，那就是它了。可以通过多种方法减少HTTP请求，例如合并图片，合并JS和CSS等等。这一点薄荷网有很多改进的余地，首先应该把现在的JS合并了。
规则2，使用内容发布网络
内容发布网络就是CDN了，但是CDN似乎挺贵的，目前还不适合薄荷网，不过可以考虑自己弄一个网通的静态资源服务器解决有中国特色的可恶的南北互通问题。
规则3，添加Expires头
这个没什么好说的，是个建网站的人都应该知道。目前薄荷网图片,css,js,flash过期时间设置了3年，可以说是永久了，：） Expires有个麻烦的地方是内容更新问题，Ruby on Rails这方面处理的非常棒，它是在文件名后面自动带了资源文件的timestamp，完美解决。
规则4，压缩组件
这个也没什么好说的，配置一下web server的压缩功能，减少服务器带宽，加快响应，立杆见影。
规则5，将样式表放在顶部
这条有点新鲜，虽然平常都是这么做的，但是没有想过不这样做有什么麻烦。如果不这样，浏览器是不能做到边下载边显示，用户体验很糟糕。薄荷网现在有部分样式没放在顶部，回头检查测试一下看看。
规则6，将脚本放在底部
这条是第一次听说，有些震惊。原因在于浏览器下载执行脚本的时候，会阻塞其他资源的下载，这样导致整体响应时间变长。薄荷网的脚本几乎都是放在顶部的，回头测试比较下看看。
规则7，避免CSS表达式
CSS表达是简直像个Bug，可以弃用，寻求变通的解决方便，比如事件处理器等。
规则8，使用外部的JavaScript和CSS
相信大家大部分情形下都是使用外联的，但纯粹的处理而已，内联JS和CSS似乎更快，考虑到缓存和复用，大部分情况显然是外联更划算。因此，在一些情景，例如首页，还是可以使用内联的。
规则9，减少DNS查找
DNS耗费的时间是相当可观的，因此同一页面的域名数量最好控制在2~4之间。
规则10，精简JavaScript
精简JavaScript可以显著减少Js文件的大小，减少下载时间。
规则11，避免重定向
get的重定向可以通过web server的url rewrite很好解决。
规则12，移除重复脚本
重复的脚本既增加一次http请求，又要重复执行，当然坚决移除了。
规则13，配置ETag
目前web server的ETag实现不但起不到好的效果，通常还使性能变得更差，真是一个糟糕的设计。所以静态资源尽量去除ETag配置。但是对于刷新频率不高的Rails动态页面，这个似乎是个不错的大幅加快响应的方法，值得再深入好好研究一番。
规则14，使Ajax可缓存
就是使用之前的规则应用于Ajax请求）
对于前端优化技术，我之前根据已经从 14 条增加到 34 条的 Exceptional Performance 做了一份笔记：
· Web 前端优化最佳实践之 Mobile(iPhone) 篇
这些最佳实践看似没什么艰深的技术含量，而网络上也能看到很多关于网络前端优化的文章，但是实际上我发现能操作、执行下去的网站还是不多，更多的时候，大家把类似的信息当成参考信息而已，看过，丢掉，如此而已。Web 前端优化的时间准则有些其实也算是常识。我曾经听到过某家大型网站的案例：用户反映网站速度慢，进行了多次技术会议，多个方案评估之后，"发现"是图片拖慢了整个网站，于是，大家的意见统一了，建设更多的 CDN ... 可实际上，这个问题或许不需要过多的投入研究，简单的分析一下页面元素比例就知道了。
这本《高性能网站建设指南》的内容以最初的 14 条优化准则写的，精炼简洁(几个小时就能读完)，我觉得已经抓住了前端优化的至少 80% 的内容，加上书中的一些引申内容(尤其是涉及到的 RFC)，如果这些都能做好，那么已经能够解决绝大部分问题了。所以是绝对值得网站运维人员一读。而且，我也认为这是 Web 2.0 网站架构不可或缺的图书 之一。
另外，发现博文视点的这一批 O'Reilly 的图书都是有索引的，很难得。
592
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
