webpack打包方案优化

优化方案

● vendor.js为整个工程依赖的基础包，工程依赖不会经常变动，所以不需要每次都重新加载，需要生成稳定的chunkId和moduleId，并且搭配http响应头ETag实现协商缓存。

● 异步chunk的依赖并不会打包到vendor.js，如果需要可以将依赖在webpack的entry入口文件中通过import引入(或者webpack配置如下)。

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

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

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

生成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提取出来，因为：

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。

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包能够被缓存。

转载于:https://juejin.im/post/5d09dde4f265da1bbf692121