你尚未登录,仅允许查看本站部分内容。请登录使用邀请码注册
前端农民工

All In One的打包策略 6个回复 专栏 @ 架构

前端农民工 发布于 3 年前

前端工程的核心是模块化框架,实践总结发现,模块化框架会关联 工具规范部署性能 等工程问题。

原则上讲,选择了一种模块化框架,就要选择其配套的工具及规范。

类似选了seajs,就要接受spm,接受了require.js,要接受它的r.js一样。当然也可以自己DIY工具,但有些规范基本上是天生定义好了的。

所以模块化系统设计上,我比较推崇业务根据场景来定制,包括框架和工具,不同的场景会有不同的模块化需求,完全通用的可能性不大,而且模块化框架本身逻辑并不复杂,定制的成本极低。

关于all in one,相信是因为不能同时做到按需、合并请求才不得已选择的结果,aio(all in one)的模块化体系,在demo层面看不出有什么问题,这是非常具有迷惑性的,等到项目用上了,达到一定规模了,才会发现这种方式的弊端:

  1. 对于传统PC,aio之后,跨页面之间共享缓存将失效。比如有A、B两个页面,A页面用了 a, b, c, d 四个模块,B页面用了 a, b, e, f,对每个页面进行aio,那么,用户在访问A页面之后再访问B页面时,重复下载了 a, b 这两个资源的内容,使得性能变差。
  2. 对于SPA应用,aio之后,首次渲染会性能变差,SPA有很多虚拟页面,不应该放到首次去加载,而是按需的,首页需要什么资源就加载什么,后续hash跳转加载页面才再做进一步的请求,这样比较合理
  3. aio还会引起资源本身的缓存失效率提升。比如一个aio中使用了 a, b, c, d 四个模块,每个模块因业务开发而需要修改的概率是p,那么aio这个文件本身被触发修改的概率就是 1- (1-p)⁴ ,假设p是20%,那么aio文件发生修改的概率将达到60%,每次修改,都会导致原来用户浏览器中的aio缓存失效,因此一个aio里合并的越多,发生修改的概率就越高,最后带宽浪费也就越多。

所以,根据实践总结,合理的打包策略应该是:

  1. 经常修改的文件极少修改的文件 分开打包,可有效提升缓存利用率
  2. 多页面共用的文件极少页面会用的文件 分开打包,可有效提升用户跨页面浏览的缓存命中率
  3. 支持按需加载的动态合并 可有效提升SPA应用的展现性能

这三条原则,本身也有一些矛盾的地方,最终确定的打包方案应该是根据业务权衡的。当然,我可以补充一条:

当且仅当业务规模很小,缓存命中、按需加载收益不明显时,aio的方式才因为没那么矬而不被察觉其劣势。

个人觉得,市面上这些模块化框架及其配套工具比较坑爹,demo把缺点隐藏的很好,上手很happy,吃亏的是后面大规模应用。

  • berg

    aio就是懒人打包方案,一旦js越来越多,如果没做模块化加载,删也不敢删,改代码也要特别小心。做大了的业务,因为这个问题,花上好几周时间做重构,这样的事情我见过不下20次了……

    要说之前,业界没有方案,而且大家没有意识,这样做还情有可原。

    如果你现在还在这么打包,就弱爆了!

    #1
  • HJin

    最近项目在重构。把 aio 拆包。

    基本上就是 common 包 和 具体页面的 js。

    不知道有没有数据说明在移动端两个 script 请求对加载速度有多少影响呢?

    #2
  • berg

    @HJin 做统计,小流量上一部分,比对两个页面看谁的速度快

    这里涉及到两个问题

    1. 怎么统计。页面打点+曲线报表
    2. 速度怎么定义。一般我们按照首屏时间和白屏时间来算,做一个加权和
    #3
  • HJin

    @berg 得用公司内部的统计服务了。打点报表似乎都能完成。

    #4
  • berg

    @HJin 你是度厂的吧,这个内部都有服务的。

    #5
  • HJin

    @berg 嗯,有。dp。正在重构接 DP。

    #6
登录后回复,如无账号,请使用邀请码注册