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_ 选项自动处理 预压缩文件. Cal 也指出这个特性在些旧版本浏览器上会出问题.

　　压缩另个主要手段是内容压缩. 针对 JavaScript 可以进行通过减少注释、合并空格、使用紧凑语法等小窍门技巧(Google 所有脚本都非常难读而且非常紧凑思想类似).当然经过这样处理 JavaScript 可能带了很多括号不容易解析Flickr使用了Dojo Compressor来构建解析树Dojo Compressor 开销很低而且对于最终用户是透明. JavaScript 处理思路方法介绍过CSS 处理则相对简单.通过简单正则表达式替换(比如把多个空格替换为个空格符), 最高可以获得 50% 压缩比

　　Caching 优化Flickr开发者充分利用了 Http 1.1 规范标准定义Etag 和 Last-Modied 机制来提高 Caching 效率. 值得注意是Cal 介绍了个在负载均衡条件下 e-Tag 小窍门技巧. 即可以设定 Apache 通过文件调整时间和文件大小获得 E-Tag ,而默认情况下, Apache 是通过文件节点获取 e-Tag 当然这也不是很完美会影响 -modied-since

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

　　通过这几个主要思路方法运用我们看到了如梦幻般高性能Flickr.

　　BTW: 在 Flickr 在国内没有服务器, 大陆用户访问速度就别提了 :(

　　--End.