Webpack优化问题
打包流程
webpack 的打包流程大致可以分为以下几个步骤：
- 初始化：webpack 通过配置文件和 Shell 参数，初始化参数，确定入口文件、输出路径、加
载器、插件等信息。接下来读取配置文件，并合并默认配置、CLI 参数等，生成最终的配置
对象。 - 编译：从入口文件开始，递归解析模块依赖，找到所有需要打包的模块。之后使用 loader 对
每个模块进行转换，转换成浏览器能够识别的 JS 代码。 - 构建模块依赖图：webpack 会为每个模块创建一个模块对象，并根据模块的依赖关系，生成
一个模块依赖图（Dependency Graph）。 - 生成代码块（chunk）：根据入口和依赖图，将所有模块分组，生成一个个包含多个模块的代
码块（chunk），这些 chunk 会根据配置生成不同的输出文件。 - 输出：将生成的代码块输出到指定的文件夹，并根据配置生成对应的静态资源文件。
- 插件处理：在整个构建过程中，webpack 会在特定的生命周期钩子上执行插件，插件可以对
打包的各个阶段进行干预和处理。
正是因为了解 webpack 整体的打包流程，所以我发现了很多可以优化的地方，然后进一步着力于
构建的优化，大幅度缩减了构建所花费的时间。
首先使用了一个插件叫 speed-measure-webpack-plugin 来查看构建时间，各个阶段的耗时吧。
分析结果来看的话，babel 编译 js 是比较耗时的，应该是还有一些 loader 处理也比较耗时。这里就有2个优化方案：
- swc 替换 babel 进行编译。
- thread-loader 来解决 loader 解析耗时问题
还有一些其他的手段来处理。最终的话效果是比较好的，降到了20s左右。
swc
它是 rust 写的 js 的编译器，编译速度非常快，而且能够兼容 babel 插件的配置，这样迁移起来没有什么成本。就这一个替换就减少了一大半的时间，它是占大头的。
我记得去年年底，yyx 说要用 rust 重写 Vite。
thread-loader
它可以通过多线程的来处理 loader 的操作，这样就减少了主线程的负载。这样那些css，图片，vue等loader的总耗时时间也减少了。
剩下的话就是一些细枝末节了，不过也是有一些作用的。
webpack5 新特定是持久化缓存，就是把模块的编译结果，解析结果，还有插件的执行结果缓存起来。后续构建就可以重用了。（这个和 Vite 的依赖预构建很像）
这块提一下吧，之前 Webpack这里也没有做什么特殊处理，就是一些简单的初始配置。后来查阅资料时发现其实在 Webpack4 版本也是有一些优化项的，
比如 cache-loader，在一些开销比较大的 loader 前加是可以将上一个loader 的结果缓存下来，下一次再走这个流程时就会根据一些规则跳过后面 loader 的处理来提高效率。
比如 DllPlugin 和 DllReferencePlugin 搭配使用来，对一些不常用的依赖，单独生成动态链接库，来提高构建速度。
module.exports = {
// ...
cache: {
// 将缓存类型设置为文件系统,默认是memory
type: "filesystem",
buildDependencies: {
// 更改配置文件时，重新缓存
config: [__filename],
},
},
optimization: {
// 值为"single"会创建一个在所有生成chunk之间共享的运行时文件
runtimeChunk: "single",
moduleIds: "deterministic",
},
};
hash
还有一个小点，就是这个 hash 的问题。
Webpack下是有3种 hash 的，content-hash，chunk-hash，hash（整个项目），这个是为了在生产环境下利用浏览器缓存机制来优化资源获取的。
开发环境下就不需要哇，本来就会频繁的更改代码。所以就把这个计算 hash 所消耗的时间也给删掉了。
升级插件
最后一个的话，是一个插件的升级。因为本来就升级到 Webpack5 了嘛，对应的一些插件肯定也要去兼容一下，其中有一个 terser-webpack-plugin 的插件，它是用来做压缩的。然后就看到它的更新日志上，好像是从 5.x 版本也引入了 swc 压缩器，升级后发现速度又变快了。
整体来说，主要用到了5个技术：
- SWC
- thread-loader
- webpack5的持久化缓存
- hash
- terser-webpack-plugin
其实看 CHANGE_LOG 有时是可以发现一些被修复的问题的，比如 element-ui 升级版本对 table 组件的问题。
依赖对 node 版本的需求。也可以说下查看 npm 依赖的 CHANGE_LOG
大概就是这样。
以上。
之后详细总结。
原文地址：https://blog.csdn.net/qq_40147756/article/details/142486139
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！