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