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包可以被缓存。