摘要：的生產環境優化完整配置的可以參考本文主要介紹了生產環境我都做了哪些優化文章的結構如下靜態資源路徑。分配不同的關于穩定性的坑注意區分整個項目有變動時，變化。而生產環境可以這一項，因為我們不需要在生產環境調試代碼。

webpack4完整配置的可以參考： https://github.com/ziwei3749/...

本文主要介紹了 webpack4 生產環境我都做了哪些優化

文章的結構如下：

1.靜態資源路徑。

2.hash 緩存。

3.代碼分割。

4.壓縮混淆代碼。

5.開啟 gzip 壓縮。

6.關閉 devtool。

7.Tree Shaking

靜態資源包括: js css image，

靜態資源的路徑的組成: 前綴 + 自己設置的路徑

前綴 ：靜態資源的路徑配置的前綴通過 output.publicPath 設置

關于publicPath的解釋 https://juejin.im/post/5ae9ae...

自己設置的路徑

js 的路徑配置

js 的路徑配置在 output.filename

output: {
    path: path.resolve(__dirname, "../dist"),
    filename: "static/js/[name].[contenthash:8].js"
}

css 路徑配置

css 的路徑配置在分離 css 的插件里。例如之前的 extract-text-webpack-plugin 或者 mini-css-extract-plugin

plugins: [
    new MiniCssExtractPlugin({
        filename: "static/css/[name].[contenthash:8].css"
    })
];

image 路徑配置

img 的路徑配置在 url-loader 里配置

modules: {
    rules: [
        {
            test: /.(png|jpe?g|gif|svg)(?.*)?$/,
            use: [
                {
                    loader: "url-loader",
                    options: {
                        limit: 10000,
                        name: "static/images/[name].[hash:7].[ext]"
                    }
                }
            ]
        }
    ];
}

ps: 有的前端同學，可能像我一樣不太清楚如何驗證打包壓縮后的的文件內路徑配置的是否正確

推薦一個簡單的方法。下載 express 項目腳手架生成一個 node 項目，將打包后的 dist 扔到 public，啟動 node 服務器

npm install express-generator -D

當然也可以直接去打開 dist 文件夾里的路徑，去確實路徑是否正確。

將業務代碼、第三方類庫、runtime 代碼、css 多帶帶打包，給他們不同 hash，來最大化利用緩存

webpack3 中分離業務代碼、第三方類庫需要用 CommonChunksPlugin。
webpack4 的新增 optimization,可以方便的分離代碼，而且 hash 的穩定性的問題也有改進。

多帶帶打包業務代碼、第三方類庫、runtime

    optimization: {
        splitChunks: {      // 打包 node_modules里的代碼
            chunks: "all"
        },
        runtimeChunk: true,  // 打包 runtime 代碼
    }

多帶帶打包 css 代碼

webpack4 推薦 mini-css-extract-plugin

注意: 之前的 extract-text-webpack-plugin 需要 beta 版本才支持，而且 contenthash 無法使用。

分配不同的 hash

關于 hash 穩定性的坑

注意區分

[hash] ： 整個項目有變動時，hash 變化。

[chunkhash] ： chunk 有變動，chunkhash 變化

[contenthash] ： 目前文檔沒有明確定義和說明，但是和文件內容的變化相關

在分離 js 和 css 時，都用設置 contenthash.

  output: {
    path: path.resolve(__dirname, "../dist"),
    filename: "static/js/[name].[contenthash:8].js",
    publicPath: "/"
  },

    new MiniCssExtractPlugin({
      filename: "static/css/[name].[contenthash:8].css"
    }),

配置js的文件名時，之前webpack3都是用chunkhash也沒問題，但是實踐后發現webpack4中用chunkhash，會導致，修改css時引發js的chunkhash變化，從而緩存失效。

經測試這樣的設置，的確可以分離打包，并且各自的 hash 值互相不會干擾，如果有問題的話，可以共同討論

代碼分割或者說懶加載，是 webpack 從誕生就一直標榜的功能吧。

它的作用就是把 js 分割成幾份，在用戶需要加載時才加載，這樣不用一次性加載所有 js。

那么在 webpack 里實現代碼分割并不是用配置的方式，而是通過我們寫代碼的方式來告訴 webpack 哪些代碼要分割

webpack 里有 2 種 webpack 分割方法

webpack 內置方法 : require.ensure() 和 require.include()

es2015 定義的 動態 import,import 返回 promise

require.ensure 使用 demo

// require.ensure()的 4 個參數 ： []依賴 、 callback 、 errorCallback 、 chunkName
require.ensure(
    ["./subPageA"],
    () => {
        var subPageA = require("./subPageA");
    },
    "subPageA"
);

// require.include("./moduleA.js")可以提取異步模塊中的公共部分到父chunk

import 使用 demo

import("./subPageA").then(subPageA => {
    console.log(subPageA);
});

// 區別
//  import("./subPageA")會直接執行這個文件，
//  而require.ensure()不會直接執行，是在里面的回調函數里才執行的引入操作。

關于import的使用注意

@babel升級后，使用import的語法，需要下載插件 @babel/plugin-syntax-dynamic-import

以下的地址鏈接
https://babeljs.io/docs/en/next/babel-plugin-syntax-dynamic-import.html

聽說webpack4只需要設置mode:produciton，就自動打包混淆js代碼啦！

很好，現在我們只需要壓縮css了可以了呢，于是下載插件optimize-css-assets-webpack-plugin

const OptimizeCssAssetsPlugin = require("optimize-css-assets-webpack-plugin")

  optimization: {
    splitChunks: {
      chunks: "all"
    },
    runtimeChunk: true,
    minimizer: [
      new OptimizeCssAssetsPlugin({})
    ]
  },

    new OptimizeCssAssetsPlugin({
      assetNameRegExp: /.optimize.css$/g,
      cssProcessor: require("cssnano"),
      cssProcessorOptions: { safe: true, discardComments: { removeAll: true } },
      canPrint: true
    }),

再看一眼我們的代碼，坑爹的發現js的壓縮居然失效了。

為什么呢？我在問答社區看到類似的問題，并且在官方文檔找到了解釋。

大致意思就是。默認optimization.minimize是true，所以js可以自動幫你壓縮

但是自定義minimizer后，webpack默認配置會取消掉。

文檔還很皮的告訴你，如果你用了css壓縮，記得自己用uglifyjs壓縮js呀。。。

https://segmentfault.com/a/11...

https://webpack.js.org/plugin...

總之，還是要自己用uglifyjs配置后壓縮js

    minimizer: [
      new OptimizeCssAssetsPlugin({}), // 壓縮 css,使用minimizer會自動取消webpack的默認配置，所以記得用UglifyJsPlugin
      new UglifyJsPlugin({
        // 壓縮 js
        uglifyOptions: {
          ecma: 6,
          cache: true,
          parallel: true
        }
      })
    ]

開啟gzip壓縮，那么壓縮的好處是什么？

可以減小文件體積，傳輸速度更快。

服務端發送 response 時可以配置 Content-Encoding：gzip，用戶說明數據的壓縮方式

瀏覽器接受時，就可以根據相應個格式去解碼。客戶端請求時，可以用 Accept-Encoding:gzip，用戶說明接受哪些壓縮方法

所以 gzip 格式在 http 中傳輸文件的話，速度更快。那么誰來壓縮文件？

不是服務端，就是客戶端咯。

服務端比如 ngix 或者 node 去做壓縮，

也可以 webpack 打包上線時，通過插件去做壓縮。

服務端響應時壓縮，肯定不如應用構建時壓縮更合適。因為壓縮也是要有時間開銷的

const CompressionWebpackPlugin = require("compression-webpack-plugin");

webpackConfig.plugins.push(
    new CompressionWebpackPlugin({
      asset: "[path].gz[query]",
      algorithm: "gzip",
      test: new RegExp(".(js|css)$"),
      threshold: 10240,
      minRatio: 0.8
    })
)

壓縮之后，文件體積減少的確顯著。

devtool我沒有做很深入的研究。

我的理解，開發環境必須要配置，否則肯定無法調試。

而生產環境可以這一項，因為我們不需要在生產環境調試代碼。如果理解有誤，歡迎指正哈~

tree shaking 的原理

ES6 的模塊是靜態分析的。所以在編譯時可以判斷哪些代碼沒有 exports

分析程序流，判斷哪些變量沒有被使用、從而刪除代碼

webpack4的新增了sideEffects來指定“有副作用的文件”，

但是我在實際使用時，遇到一些坑，比如這樣配置后，我意思是指定.css文件不要被“搖”掉。

但這個配置依舊導致了css文件打包后被當做冗余代碼被刪除。

  "sideEffects": [
    "*.css"
  ],

關于tree shaking就貼一篇文章。關于tree shaking研究清楚后再更新吧

https://zhuanlan.zhihu.com/p/...

以上就是整個配置的說明啦，目前tree shaking目前還沒有搞定，其他功能我自己測試是沒有問題的。

貼一份，webpack4完整的配置文件的地址。

如果覺得有幫助希望star一下，如果遇到問題，也歡迎指教！