likes
comments
collection
share

搞优化,主打的就是一个针对

作者站长头像
站长
· 阅读数 11

优化背景

搞优化,主打的就是一个针对

每构建一次都需要等待6分钟多一点的时间,而且产物体积偏大有14MB

优化分析

构建速度分析

搞优化,主打的就是一个针对

通过分析项目构建大部分时间都花在了sass-loader 和 babel-loader身上了。

引入thread-loader为耗时的loader开启多线程编译

搞优化,主打的就是一个针对

搞优化,主打的就是一个针对

产物体积分析

搞优化,主打的就是一个针对

通过分析会发现很多一样的包被打进了每一个chunk,这也是导致产物臃肿的直接原因

分包 (splitChunks)

搞优化,主打的就是一个针对

抽离第三方包和公共的逻辑。

效果

搞优化,主打的就是一个针对

分包的引入

这是这次优化比较棘手的问题。我们通过分包将第三方包和公共的逻辑分离出来了,导致了页面白屏。因为抽离出来打包没有引入导致的。

搞优化,主打的就是一个针对

怎么引入?

通过观察发现预发和线上的模版并不是template.html文件,而是一个叫index.xtpl的文件

搞优化,主打的就是一个针对

这很明显是一个模版引擎,如果要按这种引入,那先要找到编译这个模版的服务器(一个未知的项目),或者找对应的同学,让他帮忙把分出来的四个文件一起加入这个模板,这个同学是谁?不知道。

解决方案

最后通过一个比较粗暴的方法去处理了这个问题,就是通过一个webpack plugin 在 打包产物完成的时候,向每个产物插入一段逻辑,让它动态的去帮我们添加这些分包出来的文件。

搞优化,主打的就是一个针对

未压缩的代码

搞优化,主打的就是一个针对

END

搞优化,主打的就是一个针对

最后构建速度达到了100多秒,降了200多秒,产物体积压缩后只有1.42MB,降低了10倍

建议

做优化要对症下药,而不是乱求药,是药三分毒,乱求药可能会让你的项目的不但没有达到预期反正会病情加深,就算你求中药,那也有三分毒,就拿我的这个解释方案来说,添加了thread-loader虽然构建速度快了,但是每个线程启动也是需要时间的(600ms),添加了分包,虽然体积小了,但是要手动添加资源(因为这个项目跟普通的spa不同)。

未经允许✅

禁止转载❌

文章首发于公众号:前端疯人院

共勉!!!!!!!!!