由浅至深了解webpack异步加载背后的原理

最新推荐文章于 2024-07-15 07:45:00 发布

Geek技术前线

最新推荐文章于 2024-07-15 07:45:00 发布

阅读量1.1k

点赞数 2

分类专栏：前端框架文章标签： webpack 前端工程化异步加载

本文链接：https://blog.csdn.net/flytam/article/details/103543926

版权

本文详细介绍了webpack的异步加载和分包原理，包括相关概念如module、chunk和bundle，以及它们的区别。文章阐述了使用异步加载的好处，如利用浏览器缓存、加快加载速度和节省流量。此外，还讲解了webpack的分包配置，强调了配置项如`chunkhash`和` CommonsChunkPlugin`的作用，并讨论了`jsonpFunction`的命名问题。最后，通过实例分析了webpack如何实现异步加载，解析了打包后的代码结构和执行流程。

摘要由CSDN通过智能技术生成

源自最近对业务项目进行 webpack 异步分包加载一点点的学习总结

提纲如下：

相关概念
webpack 分包配置
webpack 异步加载分包如何实现

webpack 分包配置

在这之前，先强调一次概念，splitChunk，针对的是chunk，并不是module。对于同一个 chunk 中，无论一个代码文件被同 chunk 引用了多少次，它都还是算 1 次。只有一个代码文件被多个 chunk 引用，才算是多次。

webpack 的默认分包配置如下

module.exports = {
   
  optimization: {
   
    splitChunks: {
   
      // **`splitChunks.chunks: 'async'`**。表示哪些类型的chunk会参与split。默认是异步加载的chunk。值还可以是`initial`（表示入口同步chunk）、`all`（相当于`initial`+`async`）。
      chunks: "async",
      // minSize 表示符合代码分割产生的新生成chunk的最小大小。默认是大于30kb的才会生成新的chunk
      minSize: 30000,
      // maxSize 表示webpack会尝试将大于maxSize的chunk拆分成更小的chunk，拆解后的值需要大于minSize
      maxSize: 0,
      // 一个模块被最少多少个chunk共享时参与split
      minChunks: 1,
      // 最大异步请求数。该值可以理解为一个异步chunk，被抽离出同时加载的chunk数不超过该值。若为1，该异步chunk将不会抽离出任意代码块
      maxAsyncRequests: 5,
      // 入口chunk最大请求数。在多entry chunk的情况下会用到，表示多entry chunk公共代码抽出的最大同时加载的chunk数
      maxInitialRequests: 3,
      // 初始chunk最大请求数。
      // 多个chunk拆分出小chunk时，这个chunk的名字由多个chunk与连接符组合成
      automaticNameDelimiter: "~",
      // 表示chunk的名字自动生成（由cacheGroups的key、entry名字）
      name: true,
      // cacheGroups 表示分包分组规则，每一个分组会继承于default
      // priority表示优先级，一个chunk可能被多个分组规则命中时，会使用优先级较高的
      // test提供时 表示哪些模块会被抽离
      cacheGroups: {
   
        vendors: {
   
          test: /[\\/]node_modules[\\/]/,
          priority: -10
        },
        default: {
   
          minChunks: 2,
          priority: -20,
          // 复用已经生成的chunk
          reuseExistingChunk: true
        }
      }
    }
  }
};

还有一个很重要的配置是output.jsonpFunction（默认是webpackJsonp）。这是用于异步加载 chunk 的时候一个全局变量。如果多 webpack 环境下，为了防止该函数命名冲撞产生问题，最好设置成一个比较唯一的值。

一般而言，没有最完美的分包配置，只有最合适当前项目场景需求的配置。很多时候，默认配置已经足够可用了。

通常来说，为了保证 hash 的稳定性，建议：

1、使用webpack.HashedModuleIdsPlugin。这个插件会根据模块的相对路径生成一个四位数的 hash 作为模块 id。默认情况下 webpack 是使用模块数字自增 id 来命名，当插入一个模块占用了一个 id（或者一个删去一个模块）时，后续所有的模块 id 都受到影响，导致模块 id 变化引起打包文件的 hash 变化。使用这个插件就能解决这个问题。

2、chunkid 也是自增的，同样可能遇到模块 id 的问题。可以通过设置optimization.namedChunks为 true（默认 dev 模式下为 true，prod 模式为 false），将chunk的名字使用命名chunk。

1、2 后的效果如下。

3、抽离 css 使用mini-css-extract-plugin。hash 模式使用contenthash。

这里以腾讯云某控制台页面以下为例，使用 webpack 路有异步加载效果后如下。可以看到，第一次访问页面。这里是先请求到一个总的入口 js，然后根据我们访问的路由（路由 1），再去加载这个路由相关的代码。这里可以看到我们异步加载的 js 数为 5，就相当于上面提到的默认配置项maxAsyncRequests，通过waterfall可以看到这里是并发请求的。如果再进去其它路由（路由 2）的话，只会加载一个其它路由的 js(或者还有当前没有加载过的 vendor js)。这里如果只修改了路由 1 的自己单独业务代码，vendor 相关的 hash 和其它路由的 hash 也不是不会变，这些文件就能很好的利用了浏览器缓存了