搭建业务的性能优化指南

摘要：对于采用源码开发的业务，自然不存在什么运营成本，性能优化起来就比较顺手；对于采用模块搭建的业务，由于搭建体系天然不是性能最优的架构，性能优化就相对没那么自然。

这是一篇搭建业务优化的心路历程，也是写给搭建业务的性能优化指南。

前言

直到今天，淘内的页面大多都迁移到了 SSR，从我们终端平台 - 搭建研发团队的视角看，业务大致可以分为两类 —— 搭建派和源码派。

这两者互不冲突，更多是基于业务灵活运营和开发维护成本的考量，大致遵循以下原则：

而且已知搭建页面性能较差，源码页面性能更好的情况下，我们又加入了“性能”这个维度，构成了一个性能优化的“不可能三角”，即：

对于采用源码开发的业务，自然不存在什么运营成本，性能优化起来就比较顺手；对于采用模块搭建的业务，由于搭建体系天然不是性能最优的架构，性能优化就相对没那么自然。

笔者作为【搭建派】solution 的开发者，从一开始就注定要肩负着媲美源码派性能的重任。

下面来说说搭建派是如何打破这个不可能三角的，请收好你的搭建优化指南！

搭建优化指南

要想解决搭建的性能问题，我们就要先了解搭建慢在哪里？

搭建体系依赖 feloader（模块加载器） + seed（依赖、版本声明文件），相比源码，不仅输出的主文档体积会大，而且服务端会有拉取文件、seed依赖计算等耗时。

服务端文件加载优化

经过一系列打点日志分析后发现，虽然我们已经尽可能并行处理运行时任务，但随着并行处理的资源数量增加，存在时间片抢占，导致单个任务 resolve 时间过长。

为了验证这个猜想，于是我们从扩展入手，将多个文件合并成一个单文件，果然渲染耗时显著降低约 60%，这也为我们后续其他优化打下了基础。

Seed缓存

服务端文件加载优化减少了运行时处理任务的数量，但是即使是单个任务也存在 seed 计算的耗时，于是我们开始了针对 seed 部分的改造处理，重新 review 了代码进行了优化，并且在有了服务端文件加载优化的基础下，开启seed 缓存变为了可能。

无论是服务端文件加载优化还是 seed 缓存，这二者都是针对运行时做的优化，但是模块加载还是存在多个并行任务，相比于扩展的低复杂度以及单仓库，将模块打包成单文件不太现实，保持现状似乎就是最终的方案了？

但是毕竟还是存在一部分开销，而且每次主文档返回我们都要输出一大坨 seed 信息来让 hydrate 正常工作，始终达不到源码的效果。模块维度的运行时优化似乎没有什么改造空间了，那能不能干掉以 feloader + seed 的动态加载逻辑？Why Not！我们接着往下看。

搭建构建源码

搭建业务由于存在运行时动态拉取模块、计算依赖等操作，相比于源码项目存在着天然的性能劣势。

有句话说的好：打不过就加入！

好汉不吃眼前亏，外表上看虽然是搭建，但其实我也可以是源码。

于是为了帮助搭建业务更好的完成性能指标，我们推出了 搭建构建源码 这个方案，也就是 AOT (Ahead Of Time) 构建，简单说就是提前收集页面搭建模块然后生成源码项目进行构建。

说起搭建就离不开 feloader + seed 体系，这里就不再过多介绍，ATA 也有很多相关文章介绍，感兴趣可以自行搜素阅读。

社区开发中，主流的模块规范是 commonjs（CJS）和 esmodule（ESM），也有诸如 AMD、CMD 等规范，feloader 是基于 CMD 规范的模块加载器， web 开发中我们以 ESM 为主，去掉 feloader 可以约等于从 CMD 迁移到 ESM，它们之前的映射关系大致如下：

步骤CMDESM定义模块使用 define 函数定义模块使用 export 导出模块加载模块使用 require 函数加载模块使用 import 导入模块模块解析使用模块加载器解析依赖关系并加载模块使用 JavaScript 引擎内置的模块解析机制依赖管理通过定义依赖列表（Seed）来管理模块依赖通过模块引入语句来管理模块依赖模块执行顺序异步加载模块，按照依赖顺序执行同步加载模块，按照调用顺序执行导出模块使用返回值或导出对象来导出模块使用 export 关键字导出模块导入模块使用回调函数参数或全局变量来导入模块使用 import 关键字导入模块浏览器支持情况需要使用 CMD 模块加载器支持部分现代浏览器原生支持 ES 模块

搞清楚各个环节做了什么事情之后，我们的适配工作就逐渐清晰。

回归到源码的方案中，我们只需要按照标准的 npm 依赖管理进行适配即可。

搭建平台可以很容易从页面获取到所有模块的 npm 包名和版本号，有了这两个信息，在脚手架直接生成到package.json即可，另外模块的版本号根据搭建页面是正式还是测试页进行了区分，当在测试页调试的时候，会通过 semver 取到 beta 版本，确保依赖正确。

以下述依赖为例：

{"@ali/foo":">4.1.0-beta 4.1.0-beta

脚手架会将其编译为如下文件，也就是 solution 内部消费的模块的数据结构，在最小改动的前提下保证功能的正常运行：

import * as Mod0Instance from '@ali/foo';const { default: defaultExport0, ...nameExports0 } = Mod0Instance;import * as Mod1Instance from '@ali/bar';const { default: defaultExport1, ...nameExports1 } = Mod1Instance;export default {'@ali/foo': {defaultExport: defaultExport0,nameExports: nameExports0,},'@ali/bar': {defaultExport: defaultExport1,nameExports: nameExports1,},};

当然适配工作远没有这么简单，其他的就不在此过多展开。

技术层面的适配基本完成后，然后就是产品上的功能的实现，整个流程图如下：