雅虎性能十四条中有很多都是减少请求数，为了减少请求数通常我们会在上线前把js、css打包合并，图片也会sprite合并。 目前业界已经有很多关于CssSprite的自动化工具，基本解决了图片自动合并的问题，而静态资源的合并还停留在原始阶段，开发人工提供合并规则，用构建工具完成资源合并。 本文就将介绍一个静态资源自动合并自适应系统。
对于比较简单、页面比较少的网站我们很容易根据不同的页面进行资源合并，甚至将所有的资源合并到一起也不会对性能产生很大影响， 但当网站比较复杂，有很多静态资源时js、css的打包合并对于开发人员来说就是很痛苦的一件事了。即使我们花很大精力完成了静态资源的优化， 可不久你就会发现，页面请求的静态资源正在越来越大，请求数越来越多。人工维护静态资源合并会有以下几个问题 ：
- 无法及时排除不再使用的静态资源，导致资源包越来越大
- 当页面很多，静态资源之间使用关系很复杂时，人工无法梳理清楚，导致页面会加载一些没有使用的静态资源或者有用的静态资源合并到多个包里，增加了请求数
- 人工优化不具有可持续性，随着开发性能会越来越差
- 有过无线开发经验的同学都知道，移动端建立一个网络请求时间更长，所以资源合并打包会更多一些，我们需要根据不同网络进行打包适配
我们的本意是想优化性能，可到后来我们会发现网站的性能反而越来越差，还浪费了人工成本。并不是资源合并的想法有问题，它可以减少请求数，降低服务器压力确认是一个很好的想法。 但问题在于我们通过人工的手段来维护、优化这个日益复杂的合并方案，这是不可行的。我们需要一套可以自动优化静态资源合并方案的工具，这就是我们下面会提到的网站静态资源合并自适应方案。
静态资源自动合并方案是根据页面使用静态资源的情况、以及页面的pv和网络环境(pc、mobile)等因素自动生成静态资源合并规则的工具。 这里也提供了PPT和视屏给大家详细介绍的Fis的静态资源自动打包系统。
静态资源自动合并方案分为一下几个实施步骤：数据统计、数据分析、利用打包算法生成打包配置文件。
提供了一套数据采集API，运行时收集页面使用的静态资源组件，在页面渲染完成后将数据发送到数据统计平台。
自动打包前分析统计到的数据，算出每个页面的pv以及它使用的静态资源。注意这里的页面指的是使用静态资源组合是唯一的，如果有一个tpl不同的状态会加载不同的静态资源，在统计阶段就会认为是两个页面。利用分析到的数据构成下图结构：
如上图：横向为所有的静态资源资源的静态方式以及他们的访问量，纵向为网站所有的静态资源。1表示使用了这个资源，0代表没有使用该资源。通过分析统计数据和本地代码我们能够构造出该数据结构。
完成数据构造后，我们需要计算哪些资源应该合并到一起。为了衡量哪些资源需要合并，我们提出了两个概念 ：
合并收益 ： 我们知道两个资源合并到一起它的好处就是减少了请求数，从而减少了一个网络来回的时间，简称为RTT(Round Trip Time)。
合并损失 ： 当两个资源合并到一起，对于没有使用到其中资源的页面来说就是增加了请求数据量，延长了资源下载的时间。例如上图中加入d.css和e.css合并到一起，对于A、B、C、D页面来说就是一种损失。
最终收益 = 合并收益 - 合并损失
当最终收益大于0时两个静态资源会合并到一起，否则不合并。RTT表示一个网络来回的时间，网络的平均下载速度为SPEED。假设A.css和B.css合并到一起，
合并收益 = A_1的pv * RTT + A_2的pv * RTT + B_1的PV * RTT + .....
合并损失 从上图可以看到A和B在所有页面中使用到了，所以没有损失。
最终收益肯定是大于0，A和B应该合并到一起。
同理我么你可以分析d.css和e.css肯定不会合并到一起，而b.css和c.css则会合并到一起，因为在PV比较大的页面都使用了他们两个。
最终我们采用贪心算法每次将最优的资源合并挑选出来，直到完成所有的资源合并。
静态资源自动合并系统可以根据下面因素，针对不同的情况给出最优的资源合并方案。
从上面的算法中我们可以看到两个资源是否会合并，不仅取决于他们被使用的状况，还和RTT以及SPEED有关，而这两个常量则和网络状况有关。 因此该方案可以针对无线、PC、国际化等不同的网络环境给出不同的资源合并策略，从而做到在当前网络的最优化。
在数据统计期间可以表示页面是否达到首屏渲染状态，从而将静态资源分为首屏和非首屏两种类型，分别打包。减少首屏渲染时需要加载的静态资源。
同样针对js统计可以分为同步和异步使用的资源，在打包前将资源按照不同的类型区分开。
自动合并系统在目前已经覆盖的大部分百度产品线如：百度地图、移动云、百度糯米、hao123国际化、百度视屏、百度知道、百度百科等等。