一、背景

1.我们的技术栈相对比较统一，全部为Webpack+Vue+Typescript+Element-ui，基于以上情况，为了解决每条业务线重复配置打包脚本的问题，我们有一份统一的webpack打包配置脚本。

2.一些原因，这个打包脚本的启动、热更新、打包速度很慢，严重降低了前端开发同学的日常工作体验和前端开发效率。

二、问题分析

虽然慢是普遍的，但是不同阶段的慢我们还是需要单独分析，分开处理。

打包流程图

启动

在启动阶段，会进行全量的编译、构建，这个是webpack打包模式本身决定的，作为使用者无法修改（也有像Vite那样lazy的打包工具，但是那个就跳出Webpack优化范畴了，在这里不详细展开，具体的可以看我的另一篇文章2022年11月前端最新的打包&编译工具调研），但是可以利用缓存，加快编译。也可以通过编译内容的限制，减少不必要的文件打包，比如一些成熟的三方库文件等，我们使用的时候下载到项目中的就已经是打包好的，在项目启动的时候完全没必要再次进行打包。

热更新

1.根据多人反馈，热更新时会有一个进度92%的卡点，这个时间点上打开会卡1~2S，对于热更新来说这个时间成本已经很高昂了，这个肯定是我们要找到并优化的一个重点。

2.利用speed-measure-webpack-plguin对构建过程进行分析，找出消耗时间最多的流程，进行有针对的优化。

牛客的某个前端项目

不过speed-meature-webpack-plguin插件虽然强，但是他给的数字只有统计意义，并没有什么指导意义，这个还是需要结合自己的经验去找出异常的地方去做优化。

构建

构建过程与启动过程最相似，但是因为构建完成后的代码要部署在生产环境而不是用来本地调试，所以也有不一样的地方。例如：构建可能不需要生成source-map,构建的产物代码还要进行压缩和混淆等。

三、着手优化

原则：拆掉没必要的，替换性能更好的。

1.将ts-loader替换为babel+babel preset解析。

2.在本地dev模式下，将css由使用MiniCssExtractPlugin提取css文件的方式，改为使用style-loader的注入方式，减少编译阶段的文件生成，有效解决（缓解？多入口是否必要）了92%环节的卡点问题。

3.将我们自己写的编译插件替换为tailwindcss官方指导的插件组合，从而使原先的串行编译效果改为并行编译。

自研编译插件运行钩子

4.将dev模式下的默认全量sourceMap改为eval-sourceMap，平衡debug易用性和响应性能。

5.个别项目(fe-hr-console)启动时加载模块太多，实际开发中只用到少部分模块，多余部分的模块加载拖慢了项目启动速度与热更新编译速度，编写node脚本，结合webpack插件实现分模块启动（脚本不具备通用性，这里就不贴给大家了），从而实现与微服务架构同样的效果。

6.将我们的npm包版本分析插件默认关闭，按需开启，减少每次启动时的时间消耗。

7.引入ESBuild，替换压缩工具terser-webpack-plguin

8.配置babel-loader的扫描编译目录

9.引入babel-loader和vue-loader缓存机制

四、结果&未来展望

对文章而言，Webpack优化，网上的文章多的数也数不过来，我写的肯定不是最全面的，只是对最能解决我们的问题的方法的一些工作记录，如果大家有这方面的需求的话，还是推荐大家多了解一下这方面的知识，多看一些文章然后有针对性的找出自己项目的痛点才能事半功倍。也欢迎大家在有这方面问题的时候和我交流。

关于我做了以上的这些工作取得了哪些结果，和对于未来的展望，大家可以看我的另一篇文章：2022年11月前端最新的打包&编译工具调研。