"Times New Roman", Times, serif; align="center">案例分析：Flickr 开发者 Web应用优化技巧

Flickr Web 2.0 代表站点. 面对 网络问题除了一般 Web 站点都会有 内容优化之外, 还有必须要灵活处理 JavaScript 与 CSS 频繁变化后部署分发带来 复杂性.

设定文件大小 策略 首先面临 一个问题 把所有 JavaScript 与 CSS 放到一个文件中好呢, 还 分割成多个文件 ? 从减少网络请求 角度上考虑, 前者更好, 后者差. 但 从并行 角度考虑, IE 与 Firefox 默认情况下都只能同时从一个域请求两个资源. 这会在很多情况下给用户带来不良 使用体验--必须所有 文件都下载完毕才可以看到像样 页面. Flickr 采用了折衷 办法--在保持文件数量尽可能少 情况下, 把 JavaScript 与 CSS 分成多个子文件. 这在开发上带来了复杂性, 但 对性能 收益 巨大 .

压缩 优化问题 毫无疑问, 对站点内容进行压缩 一个比较常用 Web 优化手段．但 并不一定都能达到理想 效果．原因在于 mod-gzip 模块不但消耗服务器端 CPU 资源, 消耗客户端 CPU 资源. 而且, mod_gzip 压缩文件后创建 临时文件 放到磁盘上 , 这 会给磁盘 IO 带来严重 问题. Flickr 采用 Httpd 2.x 以后支持 　mod_deflate 模块．压缩操作都在内存中进行．mod_deflate 在 Httpd 1.x 不可用 , 不过可以通过创建 RAM 盘 方式来间接提高性能．

当然, 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 开发者充分利用了 Http 1.1 规范定义 Etag 与 Last-Modified 机制 来提高 Caching 效率. 值得注意 , Cal 介绍了一个在负载均衡条件下 e-Tag 小技巧. 即可以设定 Apache 通过文件调整时间与文件大小获得 E-Tag ,而默认情况下, Apache 通过文件节点获取 e-Tag . 当然, 这 不 很完美, 因 会影响 if-modified-since .

灵活运用 mod_rewrite 据说 Flickr 网站应用 进行每日构建 (Daily Build). 如果没有一个灵活 机制恐怕这 不可想象 . 而且, 在 Flickr 这样 站点, 内容 修改同步 处理都 很让人头疼 难题. 他们 利器 mod_rewrite 灵活运用. 通过配置 URL 重写规则, 很容易切换到不同 环境下. 听起来很简单, 但 没有一定 Web 技术功力谈何容易做到 ?!