最近我们在优化Qzone的静态资源架构的时候，遇到了一个问题，这个问题需要我们对请求、缓存、图片利用率、人力成本这几点来权衡。前端性能的优化就是关于权衡，很多事情都没有一个完美解决方案。要针对具体需求进行优化。

请求

请求很简单，所有了解前端性能优化的人都能脱口而出：HTTP请求越少越好。

HTTP请求少于 一定数量的时候，减少请求就没有意义了。

页面上有些不重要的模块可以用ajax来延迟加载，这时候延迟加载的html和css以及图片，就没有必要计算请求数了，这也是为了减少初次加载的时候的文件大小。

缓存

当用户第一次访问过了一个页面之后，服务器可以吐出静态资源，并且在response header中声明max-age比如一年，那么这一年之内理论上用户访问页面的时候都不会再向服务器请求这个资源，这样就节省了请求和带宽。

为什么说理论上呢，因为实际上这个静态资源保存在用户的缓存池中，这个池是有限的（据说chrome的缓存池是自动扩展的？待求证），那么后续缓存的资源会把前面载入的资源挤出去。当发生了这种情况，请求前面的资源的时候就会重新请求服务器了。

那么服务器端如果要修改这个资源呢？如何让用户的浏览器重新拉取资源？答案是url加上时间戳，比如xxx.png?d=20120523，那么浏览器会认为是另一个文件而重新请求，而服务器也会吐出xxx.png来。

请求和缓存之间的矛盾是当站点有多个页面需要有一部分内容是相同的图片的时候，如果我们专注于最小化请求，那么就会把所有能合并的图片合并起来，那么两个页面调用各自的雪碧图，这样就损失了一部分本可以在两个页面之间共用的图片。

图片利用率

图片利用率这个概念常用于复杂的社交网站，比如facebook和QZone。因为对于这类型的网站的一个重要特点是，每个人看到的页面都不一样。我可以自定义我的主页的模块，边栏显示的模块，并且我的feeds中出现的条目也跟其他人不一样。而传统网站是每个人看到的页面都一样，那么图片的利用率是100%。

现在我的主页有模块A，而张三的主页没有这个模块A，那么如果张三的雪碧图和打包CSS中也包含了A的渲染代码和图片的话，那就是流量的浪费，也是速度慢的一个原因。

Facebook有一套很好的服务器端动态打包系统，会根据用户模块来打包CSS和图片。

QZone也有一套服务器端动态打包的语法，但是还不够给力，一方面不能分析用户行为，另一方面不能合并图片。用的更多的是CSSgaga来让工程师合并CSS和图片。在请求和缓存上已经能达到业界最好的水平，但在图片利用率上还有待提高。

人力成本

人力成本是考量一个架构是否优秀的重要考评点。

人力成本包括实现一个功能需要的成本、维护成本、修改成本、删除成本、培训成本等……成本越低，架构更容易推行。成本越高，越会遇到阻力。

QZone现在已经有非常优秀的架构和工具，但是人力成本还是稍高，因为需要工程师实际确定最终突出代码的文件顺序、图片合并。这些并不是动态的，所以需要有经验的工程师来进行合并。所幸的是有CSSgaga来快速合并。

Facebook把精通性能优化的工程师专门用来实现服务器端动态打包系统，而其他的更多工程师只是实现自己的模块，并不实际关心最终模块的HTML、CSS、图片是如何吐出到服务器端（是直接吐？还是Ajax？是合并还是单独图片？），工程师只需要声明模块优先级即可。

这一点也是QZone现在需要学习的地方。