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 中。

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表示你发送请求时告诉服务器，我可以解压这些格式的数据。

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