前几天，对九霄项目进行了一次大范围的性能优化，效果还不错，首屏从最开始的899个请求4.98s加载，到最后29个请求998ms加载，提升了79%以上。这里记录一下优化的过程，方便有需要的朋友。
开篇
新工作已经4个多月，从0开始到现在三个子系统并行，每个子系统负责滴滴业务线的数据分析，业务量和业务逻辑相当复杂。不过随着业务的扩展，性能也随之会成为阻碍系统运转的瓶颈，性能优化势在必行。
现状
目前前端技术架构是:
seajs + arale + koa + gulp + less
页面部署是：
+ router.js
- entry[入口]
- express[快车]
- hitch[顺风车]
- daijia[代驾]
页面是由路由依次进入四个页面。由于是单页面应用，所以资源文件都是一次加载，导致子系统越多，加载文件越多，网站也越来越慢。
优化
优化一: 按需加载
从上面的架构来看，seajs模块combo在一起，合成一个 nsky.min.js 的原始发布方案已经不能满足需求了，需要划分子系统按需加载。
按需加载的意思是，进入首页时加载首页必须依赖的模块，不加载其他页面(快车，顺风车，代驾)所需资源。
seajs请求资源的原理是正则扫描每个模块中require的字符串，从而提取模块的依赖。加载模块时，首先加载其依赖文件，因此我们能够通过 combo 的方式把模块合并到一个文件。另外，seajs中提供 require.async 来实现异步加载。
因此，我们在router里面转发到不同页面的时候使用 require.async，从而实现分子系统按需加载。
优化结果如下：
首屏请求数量直接从899个优化到57个，结果还是可喜。
优化二：请求合并
观察请求瀑布流，发现请求文件还是太多，比如系统资源加载（class.js/events.js/overlay.js等)，还有业务代码较多，我们可以把这些资源合并在一起，发出combo请求。
比如发出
http://d.kuaidadi.com/path/??class.js,events.js,overlay.js,xxx.js
然后服务端响应此 combo 请求，返回 class.js, events.js, overlay.js, xxx.js的合集，这样就可以实现请求合并。
首先，需要浏览器发出类似 ??a.js,b.js,c.js 的combo请求。seajs发出combo请求很简单，通过seajs combo插件就可以了:
seajs.config({
preload: "seajs-combo"
});
其次，需要服务器端响应类似 ??a.js,b.js,c.js 的combo请求。
seajs combo插件中文文档中提到，服务端实现combo请求是通过Nginx-Http-Concat实现。
但是由于线上服务器是通过 Nginx 来实现数台生产机器间负载均衡，通过 Nginx Proxy Pass实现非80端转发到80端口。经过试验发现，Nginx的 Proxy Pass 和 Nginx-Http-Concat不能同时使用，其作者也说过暂时不支持。，所以此路不通。
因此，只能自己实现Node Combo。于是又找了不少node-combo项目(比如node-combo)，研究其实现思路，准备自己写koa-node-combo插件了。
后来搜索npm仓库，发现有多个这样的插件，尝试发现koa-combo-parse可行：
app.use(comboParse({
base: path.resolve(__dirname, '../client/')
}));
但是，问题又来了。combo到一起后系统仍然不能运行，因为文件之间没有识别的id。需要寻找工具来对每个模版补全id和依赖(deps)，combo后就能互相识别了。即需要从：
define(function(require, exports, module){
var a = require('a'),
b = require('b');
module.exports = {};
});
变成：
define('moduleId', ['a', 'b'], function(require, exports, module){
var a = require('a'),
b = require('b');
module.exports = {};
});
在此过程中调研了 spm、gulp-seajs-combo等，发现都不满足需求。
于是自己实现了node小工具 iddeps，并写成了gulp插件gulp-ids-deps。
最终，前端发出combo请求后，后端响应combo请求，效果如下：
请求数量从57减少到37，请求时间从1.4s减少到了1.18s。
优化三：模版文件预编译
从上面的瀑布流能看出，tpl文件既大又多，占用不少请求时间。
在handlebars中，有预编译的思想，可以在运行前把模版文件预编译成为 js 文件。
业界没有相应的工具，于是自己写了一个node小工具tpl-2-js，并改写成gulp插件gulp-tpl-2-js。
Handlebars预编译的过程是：
// node
var preCompileData = handlebars.precompile(data);
// web
var Handlebars = require('handlebars'),
template = Handlebars.template;
template(preCompileData)({data});
预编译的过程，是Handlebars precompile创建了一个函数，把每个template存储在 Handlebars.templates里面。
更多详细请看：gulp-tpl-2-js
经过模版预编译后、Combo后，效果如下：
可以看到，请求结果从上次的37减少到29，请求时间从1.18s减少到998ms
后续
整体结果优化的效果差不多了，请求数变到最小，时间首屏时间也符合期望。
后续的优化，可以考虑通过 html5 的 appcache 缓存不经常的更新资源文件，把 200 的资源文件变成 302。
本文是记录自己优化系统的心路历程，有不同意见或者有所收获的可以留言讨论。
原创文章，欢迎转载。转载请注明：转载自Fs21 ' s Home，谢谢！
原文链接地址：前端性能调优