八维学校分享Web应用优化技巧 Flickr是 Web 2.0 的代表站点。面对的网络问题除了一般 Web 站点都会有的内容优化之外, 还有必须要灵活处理 JavaScript 与CSS的频繁变化后部署分发带来的复杂性。
设定文件大小的策略首先面临的一个问题是把所有的 JavaScript 与CSS放到一个文件中好呢，还是分割成多个文件 ? 从减少网络请求的角度上考虑, 前者更好，后者差。但是从并行的角度考虑,IE与 Firefox 默认情况下都只能同时从一个域请求两个资源. 这会在很多情况下给用户带来不良的使用体验--必须所有的文件都下载完毕才可以看到像样的页面. Flickr 采用了折衷的办法--在保持文件数量尽可能少的情况下，把 JavaScript 与CSS分成多个子文件. 这在开发上带来了复杂性，但是对性能的收益是巨大的。
压缩的优化问题毫无疑问，对站点内容进行压缩是一个比较常用的 Web 优化手段.但是并不一定都能达到理想的效果.原因在于mod-gzip模块不但消耗服务器端CPU资源，也消耗客户端CPU资源. 而且, mod_gzip 压缩文件后创建的临时文件是放到磁盘上的，这也会给磁盘IO带来严重的问题. Flickr 采用的是
当然, mod_gzip 到也不是一无是处, 对于预压缩的文件, 还是有好处的. 而且, 采用压缩的时候,也要注意策略. 图片文件压缩就没什么必要了(Flickr 上图像多, 而且压缩得不到什么好处). Flickr 只对 JavaScript 和CSS进行压缩. mod_gzip 新一点的版本能够自动通过配置 mod_gzip_update_static 选项自动处理 预压缩的文件. Cal 也指出这个特性在一些旧版本的浏览器上会出问题.
压缩的另一个主要手段是内容的压缩. 针对 JavaScript 可以进行通过减少注释、合并空格、使用紧凑的语法等小技巧(Google 的所有脚本都非常难读，而且非常紧凑，思想类似).当然，经过这样处理的 JavaScript 可能带了很多括号不容易解析，Flickr使用了Dojo Compressor来构建解析树。Dojo Compressor 开销很低，而且对于最终用户是透明的. JavaScript 的处理方法介绍过，CSS 处理则相对简单.通过简单的正则表达式替换(比如把多个空格替换为一个空格符), 最高可以获得 50% 的压缩比。
Caching 的优化Flickr的开发者充分利用了 。
灵活运用 mod_rewrite据说Flickr网站应用是进行每日构建的(Daily Build)。 如果没有一个灵活的机制恐怕这是不可想象的。而且，在 Flickr 这样的站点, 内容的修改同步的处理都是很让人头疼的难题. 他们的利器是mod_rewrite的灵活运用。通过配置URL重写规则，很容易切换到不同的环境下。听起来很简单, 但是没有一定的 Web 技术功力谈何容易做到 ?!
