webpack打包方案优化

2019年11月17日 阅读数:13
这篇文章主要向大家介绍webpack打包方案优化,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。


优化方案

● vendor.js为整个工程依赖的基础包,工程依赖不会常常变更,因此不须要每次都从新加载,须要生成稳定的chunkId和moduleId,而且搭配http响应头ETag实现协商缓存。
html

● 异步chunk的依赖并不会打包到vendor.js,若是须要能够将依赖在webpack的entry入口文件中经过import引入(或者webpack配置以下)。
前端

  entry: {
    main: './src/index.js',
    vendor: ["moment"] //能够将异步chunk的依赖模块放到此处
  }复制代码

● 异步chunk中重复使用的模块提取到use-repeat.js,避免重复模块都打入到单个chunk包中。node

● 线上环境使用 content-encoding 实现压缩数据传输。webpack

生成vendor包

   new webpack.optimize.CommonsChunkPlugin({
      name: 'vendor',
      minChunks: function (module, count) {
        // any required modules inside node_modules are extracted to vendor
        return (module.resource && /\.js$/.test(module.resource) && module.resource.indexOf(path.join(__dirname, '../node_modules')) === 0)
      }
    })复制代码

为了保证vendor的纯净,须要将webpack runtime提取出来,由于:
web

1.webpack runtime (运行时) 中包含 chunks ID 及其对应 chunkhash 的对象,但 runtime 被集成到 vendor.js 中。
2.entry 内容修改后,因为 webpack 的依赖收集规则致使构建产生的 entry chunk 对应的 ID 发生变化,webpack runtime 也所以被改变。

    new webpack.optimize.CommonsChunkPlugin({
        name: 'runtime'
    })复制代码

生成use-repeat包

将异步chunk中,重复用到的模块(使用次数 >= 4 )打包到use-repeat,避免单个chunk重复打包高频使用的相同资源。
算法

    new webpack.optimizeea.CommonsChunkPlugin({
      async: 'use-repeat',
      minChunks: (module, count) => (count >=4)
    })复制代码

固定moduleId

在官方文档: 官方文档-缓存说起,由于每一个 module.id 会基于默认的解析顺序(resolve order)进行增量。也就是说,当解析顺序发生变化,ID 也会随之改变,因此须要固定moduleId。

    new webpack.HashedModuleIdsPlugin({
      hashFunction: 'md5',
      hashDigest: 'hex',
      hashDigestLength: 8
    })复制代码

固定chunkId

不少文章都只介绍到如何生成稳定的ModuleId,没有提到生成稳定的chunkId。
api

webpack是根据模块的顺序递增chunkId,官方有提供 NamedChunksPlugin插件来根据文件名来稳定工程的chunkId。
webpackJsonp有三个参数,每次有新的entry加入说明资源数增长了,Chunk数量也会跟着增长。ChunkId也会递增。

    new webpack.NamedChunksPlugin((chunk) => {
      if (chunk.name) {
        return chunk.name;
      }
      return chunk.modules.map(m => path.relative(m.context, m.request)).join("_");
    })复制代码

ps: 在webpack3.8.1,chunk modules 被废弃。
浏览器

设置content-encoding & accept-encoding

content-encoding是指网页使用了哪一种压缩方式传输数据给你,accept-encoding表示你发送请求时告诉服务器,我能够解压这些格式的数据。
两者的关系是,对方网页会根据你发送的accept-encoding来决定用什么格式(content-encoding)传给你。没有设置 accept-encoding,默认值为:gzip,deflate。

gzip缓存

表示采用 Lempel-Ziv coding (LZ77) 压缩算法,以及32位CRC校验的编码方式。这个编码方式最初由 UNIX 平台上的gzip程序采用。出于兼容性的考虑, HTTP/1.1 标准提议支持这种编码方式的服务器应该识别做为别名的 x-gzip 指令。性能优化

compress

采用 Lempel-Ziv-Welch (LZW) 压缩算法。这个名称来自UNIX系统的compress程序,该程序实现了前述算法。与其同名程序已经在大部分UNIX发行版中消失同样,这种内容编码方式已经被大部分浏览器弃用,部分由于专利问题(这项专利在2003年到期)。

deflate

采用 zlib 结构 (在 RFC 1950 中规定),和deflate压缩算法(在 RFC 1951 中规定)。

identity

用于指代自身(例如:未通过压缩和修改)。除非特别指明,这个标记始终能够被接受。br表示采用 Brotli 算法的编码方式。

线上使用content-encodeing: gzip , 能有效减小各个js包体积60%左右,是前端性能优化的关键,若是不使用将前功尽弃。除此之外要使用到ETag,保证vendor包可以被缓存。