摘要：中在性能優(yōu)化所做的努力，也大抵圍繞著這兩個(gè)大方向展開。因此，將依賴模塊從業(yè)務(wù)代碼中分離是性能優(yōu)化重要的一環(huán)。大型庫是否可以通過定制功能的方式減少體積。這又違背了性能優(yōu)化的基礎(chǔ)。接下來可以抓住一些細(xì)節(jié)做更細(xì)的優(yōu)化。中，為默認(rèn)啟動(dòng)這一優(yōu)化。

前言：在現(xiàn)實(shí)項(xiàng)目中，我們可能很少需要從頭開始去配置一個(gè)webpack 項(xiàng)目，特別是webpack4.0發(fā)布以后，零配置啟動(dòng)一個(gè)項(xiàng)目成為一種標(biāo)配。正因?yàn)榱闩渲玫膚ebpack對項(xiàng)目本身提供的“打包”和“壓縮”功能已經(jīng)做了優(yōu)化，所以實(shí)際應(yīng)用中，我們可以把精力更多專注在業(yè)務(wù)層面上，而無需分心于項(xiàng)目構(gòu)建上的優(yōu)化。然而從學(xué)習(xí)者的角度，我們需要了解webpack在項(xiàng)目的構(gòu)建和打包壓縮過程中做了哪些的優(yōu)化，以及在原有默認(rèn)配置上，還可以做哪些性能方面上的改進(jìn)。

???????最近在完成vue的單頁面應(yīng)用后萌生了一個(gè)想法，拋棄掉vue-cli的構(gòu)建配置，從零開始進(jìn)行webpack優(yōu)化，并將過程中的思路和體會(huì)分享在這篇文章中。webpack的初始配置在我之前寫的另一篇手把手教你從零認(rèn)識(shí)webpack4.0文章中，以下內(nèi)容也不對基本的webpack配置做過多闡述。

???????對開發(fā)者而言，我們希望webpack這個(gè)工具可以給我們帶來流暢的開發(fā)體驗(yàn)。比如，當(dāng)不斷修改代碼時(shí)，我們希望代碼的變更能及時(shí)的通知瀏覽器刷新頁面，而不是手動(dòng)去刷新頁面。更進(jìn)一步的我們希望，代碼的修改只會(huì)局部更換某個(gè)模塊，而不是整個(gè)頁面的刷新。這樣可以使我們不需要在等待刷新中浪費(fèi)很多時(shí)間，大大提高了頁面的開發(fā)效率。

???????項(xiàng)目部署上線時(shí)，性能優(yōu)化是我們考慮的重點(diǎn)，有兩個(gè)方向可以作為核心考慮的點(diǎn)，一個(gè)是減少HTTP請求，我們知道在網(wǎng)速相同的條件下，下載一個(gè)100KB的圖片比下載兩個(gè)50KB的圖片要快，因此，我們要求webpack將多個(gè)文件打包成一個(gè)或者少量個(gè)文件；另一個(gè)優(yōu)化的重點(diǎn)是減少單次請求的時(shí)間，也就是盡可能減少請求文件的體積大小。
???????webpack中在性能優(yōu)化所做的努力，也大抵圍繞著這兩個(gè)大方向展開。另外在構(gòu)建項(xiàng)目中，我們也希望能持續(xù)的提高構(gòu)建效率。

開發(fā)環(huán)境下，我們依然對代碼的體積有一定的要求，更小的體積可以讓加載速度更快，開發(fā)效率更高，當(dāng)然配置也相對簡單。

// webpack.dev.js 開發(fā)環(huán)境webpack配置
module.exports = {
    devServer: {
        contentBase: path.join(__dirname, "dist"),
        port: 9000,
        compress: true, // 代碼壓縮
      },
}

開發(fā)過程中，我們希望修改代碼的過程中，頁面能實(shí)時(shí)且不需要手動(dòng)的刷新。因此使用HRM， HMR 既避免了頻繁手動(dòng)刷新頁面，也減少了頁面刷新時(shí)的等待，大幅度提高了開發(fā)效率。

// webpack.dev.js
module.exports = {
  devServer: {
    compress: true,
    hot: true // 開啟配置
  },
  plugins: [
    new webpack.NamedModulesPlugin(),
    new webpack.HotModuleReplacementPlugin(),
  ],
}

webpack 在構(gòu)建中提供了不少于7種的sourcemap模式，其中eval模式雖然可以提高構(gòu)建效率，但是構(gòu)建后的腳本較大，因此生產(chǎn)上并不適用。而source-map 模式可以通過生成的 .map 文件來追蹤腳本文件的 具體位置，進(jìn)而縮小腳本文件的體積，這是生產(chǎn)模式的首選，并且在生產(chǎn)中，我們需要隱藏具體的腳本信息，因此可以使用 cheap 和module 模式來達(dá)到目的。
綜上，在生產(chǎn)的webpack devtool選項(xiàng)中，我們使用 cheap-module-source-map的配置

// webpack.pro.js 生產(chǎn)webpack配置腳本
module.exports = {
  mode: "production",
  devtool: "cheap-module-source-map",  
}

以單入口文件而論，通常我們會(huì)將頁面的所有靜態(tài)資源都打包成一個(gè)JS 文件，這已經(jīng)實(shí)現(xiàn)了1.2 中的優(yōu)化部分，將代碼合并成一個(gè)靜態(tài)資源，減少了HTTP 請求。

分離前

但是接下來，我們需要將css代碼獨(dú)立開來，為什么呢？最主要的一點(diǎn)是我們希望更好的利用瀏覽器的緩存，當(dāng)多帶帶修改了樣式時(shí)，獨(dú)立的css文件可以不需要應(yīng)用去加載整個(gè)的腳本文件，提高效率。并且，當(dāng)遇到多頁面的應(yīng)用時(shí)，可以多帶帶將一些公共部分的樣式抽離開來，加載一個(gè)頁面后，接下來的頁面同樣可以利用緩存來減少請求。

webpack4.0 中提供了抽離css文件的插件，mini-css-extract-plugin,只需要簡單的配置便可以將css文件分離開來

const MiniCssExtractPlugin = require("mini-css-extract-plugin")

module.exports = {
    ···
    plugins: [
        new MiniCssExtractPlugin({
            filename: "[name].[contenthash].css",
            chunkFilename: "[name].[contenthash].css"
        })
    ],
    module: {
        rules: {
            test: /.(css|scss)$/,
            use: [process.env.NODE_ENV == "production" ? MiniCssExtractPlugin.loader : "style-loader", {
              loader: "css-loader",
              options: {
                sourceMap: true
              },
            }, "sass-loader"]
        }
    }
    ···
}

分離后

要想優(yōu)化構(gòu)建后的體積，不斷減少靜態(tài)資源文件的大小，我們希望webpack幫助我們盡可能壓縮文件的體積。對于js 腳本文件而言，webpack4.0 在mode 為‘production’時(shí)，默認(rèn)會(huì)啟動(dòng)代碼的壓縮。除此之外，我們需要手動(dòng)對html和css 進(jìn)行壓縮。
???????針對html 的壓縮，只需要對html-webpack-plugin進(jìn)行相關(guān)配置。

// webpack.base.js 

module.exports = {
    plugins: [
        new HtmlWebpackPlugin({
          title: "minHTML",
          filename: "index.html",
          template: path.resolve(__dirname, "../index.html"),
          minify: { // 壓縮 HTML 的配置
            collapseWhitespace: true,
            removeComments: true,
            useShortDoctype: true
          }
        }),
    ]
}

???????針對css 的壓縮， webpack4.0 使用optimize-css-assets-webpack-plugin來壓縮多帶帶的css 文件。

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

module.exports = {
    plugins: [
        new OptimizeCSSAssetsPlugin()
    ],
}

對比之下，我們可以看到明顯的效果，關(guān)于壓縮css 更多的配置可以參考o(jì)ptimize-css-assets-webpack-plugin

處理完前端的三大塊js,html,css后， 接下來優(yōu)化能想到的是處理圖片。前面提到，提升性能的一個(gè)重要的條件是降低http請求數(shù)，而應(yīng)用中經(jīng)常會(huì)有大大小小的圖片需要處理，對應(yīng)用中的小圖標(biāo)來說，css sprite 是首選，將各種圖標(biāo)集合成一張大的圖片可以很好的減少網(wǎng)絡(luò)請求數(shù)。而對于需要獨(dú)立開的圖片，且大小在合理范圍內(nèi)時(shí)，我們可以將圖片轉(zhuǎn)換成 base64位編碼，內(nèi)嵌到css 中，同樣可以減少請求。

3.4.1 base64 轉(zhuǎn)換

處理圖片資源時(shí)，webpack 提供了 file-loader 和url-loader 兩個(gè)loaders供選擇，file-loader 和url-loader 的作用，可以用來解析項(xiàng)目中圖片文件的url引入問題。兩者的區(qū)別在于，url-loader 可以將小于指定字節(jié)的文件轉(zhuǎn)為DataURL, 大于指定字節(jié) 的依舊會(huì)使用file-loader 進(jìn)行解析

// webpack.base.js
module.exports = {
    module: {
        rules: [{
            test: /.(png|jpe?g|gif|svg|ttf|woff2|woff)(?.*)?$/,
            use: [{
              loader: "url-loader",
              options: {
                limit: 10000, // 限制大小
              }
            }, 
        ]
  },
}

3.4.2 壓縮圖片

處理完雪碧圖和小圖片的base64轉(zhuǎn)換后，對于大圖片來說，webpack還可以做到對圖片進(jìn)行壓縮，推薦使用image-webpack-loader,插件提供了多種形式的壓縮，詳細(xì)可以參考官網(wǎng)文檔

// webpack.base.js
module.exports = {
    module: {
        rules: [
            {
              loader: "image-webpack-loader",
              options: {
                optipng: { // 使用 imagemin-optipng 壓縮 png，enable: false 為關(guān)閉
                  enabled: true,
                },
                pngquant: { // 使用 imagemin-pngquant 壓縮 png
                  quality: "65-90",
                  speed: 4
                },
              }
            }
        ]
    }
}

效果對比如下：

一個(gè)中大型應(yīng)用中，第三方的依賴，龐大得可怕，占據(jù)了打包后文件的一半以上。然而，這些依賴模塊又是很少變更的資源，和css 代碼分離的邏輯相似，分離第三方依賴庫，可以更好的利用瀏覽器緩存，提升應(yīng)用性能。因此，將依賴模塊從業(yè)務(wù)代碼中分離是性能優(yōu)化重要的一環(huán)。
webpack4.0 中，依賴庫的分離只需要通過 optimization.splitChunks 進(jìn)行配置即可。

// webpack.pro.js
module.exports = {
    optimization: {
       splitChunks: {
          cacheGroups: {
            vendor: {
              chunks: "initial",
              test: path.resolve(__dirname, "../node_modules"),
              name: "vendor", // 使用 vendor 入口作為公共部分
              enforce: true,
            },
          },
        },
      },
}

公共庫分離后的結(jié)果

正如前面所講，在優(yōu)化分析中，實(shí)際影響體積最大的是 node_modules 的第三方庫，這一部分的優(yōu)化可以大大的減少打包后的體積。這里我們使用最新的webpack-bundle-analyzer插件來分析打包好后的模塊，它可以將打包后的內(nèi)容束展示位方便交互的直觀樹狀圖，通過它，可以知道項(xiàng)目大致有哪些模塊組成，哪個(gè)模塊占據(jù)的體積較大，是否是可替代的。

我們大致可以從幾個(gè)方向考慮

1.判斷依賴是否不可或缺，依賴在項(xiàng)目中使用率是否過低。在項(xiàng)目中，可能針對某個(gè)運(yùn)算，某個(gè)功能，我們使用了一個(gè)龐大的庫，這個(gè)庫在體積上的占比較大，而功能使用卻較少。這個(gè)時(shí)候我們可以尋找體積更小，且功能滿足的替換庫，或者手動(dòng)實(shí)現(xiàn)某些依賴的功能來替換他。

2.大型庫是否可以通過定制功能的方式減少體積。明顯的一個(gè)例子是 echart， echart完全版的依賴壓縮后也有幾百k 之多，這顯示是難以接受的?，F(xiàn)實(shí)項(xiàng)目中，我們可能只需要少量或者部分的echart 功能，這時(shí)我們可以通過制定圖表的形式，下載圖表用到的功能，達(dá)到體積最優(yōu)化。

3.某些不可優(yōu)化的大型庫是否可以通過外部引用的方式減少文件體積。例如像bootstrap，vue這類無法優(yōu)化的第三方庫，通過免費(fèi)開源的cdn服務(wù)不但可以減少文件體積，還可以提高網(wǎng)站的加載速度，也是個(gè)優(yōu)化性能的方法

前面提到依賴分析的方向中，如果大型庫不可或缺，而且使用率也不算低的時(shí)候，我們可以通過按需加載的形式。這種方式實(shí)際上是先把你的代碼在一些邏輯斷點(diǎn)處分離開，然后在一些代碼塊中完成某些操作后，立即引用或即將引用另外一些新的代碼塊。這樣加快了應(yīng)用的初始加載速度，減輕了它的總體體積，因?yàn)槟承┐a塊可能永遠(yuǎn)不會(huì)被加載。

webpack中利用require.ensure()實(shí)現(xiàn)按需加載，在不使用按需加載的情況下，首屏加載時(shí)會(huì)把所有的腳本同時(shí)加載出來，這往往會(huì)拖累首屏顯示時(shí)間，帶來不好的用戶體驗(yàn)。例子來說。當(dāng)項(xiàng)目需要使用大型的圖表類庫，而首頁并不需要時(shí)，按需加載往往比同時(shí)加載在用戶體驗(yàn)上好好得多。

當(dāng)不需要按需加載的時(shí)候，我們的代碼可能是這樣的：

import test from "./components/test.vue"
import test2 from "./components/test2.vue"

開啟按需加載時(shí)，我們的代碼修改為：

const test = r => require.ensure([], () => r(require("./components/test.vue")), "chunk1")
const test2 = r => require.ensure([], () => r(require("./components/test2.vue")), "chunk2")

webpack 配置修改為

output: {
    ···
    chunkFilename: "[name].[hash].js"
}

這時(shí)編譯出來的文件會(huì)從原來的一個(gè)，變成了多個(gè)小文件。每個(gè)路由加載時(shí)會(huì)去加載不同的資源。特別在首屏的資源加載上進(jìn)一步優(yōu)化了應(yīng)用的體驗(yàn)。

盡管如此，實(shí)際中我們需要根據(jù)項(xiàng)目的需求來衡量按需加載的可用性，盡管在首屏優(yōu)化上取得較大的提升，但按需加載畢竟會(huì)將大的文件拆分成多個(gè)小文件，增加了http 的請求數(shù)。這又違背了性能優(yōu)化的基礎(chǔ)。所以實(shí)際中需要取舍，更需要權(quán)衡。

代碼體積優(yōu)化到這一步，基本可以優(yōu)化的地方已經(jīng)優(yōu)化完畢了。接下來可以抓住一些細(xì)節(jié)做更細(xì)的優(yōu)化。比如可以刪除項(xiàng)目中上下文都未被引用的代碼。這就是所謂的 Tree shaking 優(yōu)化。webpack 4.0中，mode 為production 默認(rèn)啟動(dòng)這一優(yōu)化。但是，如果在項(xiàng)目中使用到babel的 話，需要把babel解析語法的功能關(guān)掉。只需要

// .babelrc

{
  "presets": [["env", { "modules": false }]]
}

說完如何減少項(xiàng)目構(gòu)建后的大小后，接下來簡單的談一下如何提高構(gòu)建的速度。實(shí)際上webpack的 構(gòu)建速度，只需要簡單的修改配置便能大幅提高速度。常見的設(shè)置如下。

4.1.1 限定加載器作用范圍

由于babel-loader需要將語法進(jìn)行轉(zhuǎn)換，所耗費(fèi)的時(shí)間較長，所以第一步需要限定babel-loader 作用的范圍，讓babel-loader 的搜索和轉(zhuǎn)換準(zhǔn)確的定位到指定模塊。大幅提高構(gòu)建速度。
例如：

// webpack.base.js
module.exports = {
    module:{
        rules: [
            {
                test: /.js$/,
                include: [resolve("src")],// 限定范圍
                use: {
                  loader: "babel-loader",
                },
            },]
    }
}

4.1.2 緩存加載器執(zhí)行結(jié)果

正因?yàn)閎abel-loader在解析轉(zhuǎn)換上耗時(shí)太長，所以我們希望能緩存每次執(zhí)行的結(jié)果。webpack的loader中剛好有 cacheDirectory 的選項(xiàng)，默認(rèn)為false 開啟后將使用緩存的執(zhí)行結(jié)果，打包速度明顯提升。

// webpack.base.js
module.exports = {
    module: {
        rules: [
            {
            test: /.js$/,
            include: [resolve("src")],
            use: {
              loader: "babel-loader?cacheDirectory",
            },
        },]
    }
}

webpack 的resolve 做相關(guān)的配置后，也可以讓項(xiàng)目的構(gòu)建速度加快。具體看下文的配置：

當(dāng)項(xiàng)目中出現(xiàn) import "react" 既不是絕對路徑也不是相對路徑時(shí)，指定好搜索的路徑，可以不用過多的查詢

盡可能少的使用 resolve.alias 來設(shè)置路徑別名，因?yàn)闀?huì)影響到tree shaking 的優(yōu)化

后綴自動(dòng)補(bǔ)全盡可能的少。減少路徑查詢的工作

當(dāng)使用的第三方庫過大，并且不包含import require define 的調(diào)用?？梢允褂胣oParse讓庫不被loaders 解析

// webpack.base.js
module.exports = {
    resolve: {
      modules: [
        path.resolve(__dirname, "node_modules"),
      ],

      extensions: [".js"], 
    
      // 避免新增默認(rèn)文件，編碼時(shí)使用詳細(xì)的文件路徑，代碼會(huì)更容易解讀，也有益于提高構(gòu)建速度
      mainFiles: ["index"],
    }，
    module: {
        noParse: function(content){
            return /jquery/.test(content)
        }
    }
}

webpack性能優(yōu)化的瓶頸還是集中在構(gòu)建時(shí)間和構(gòu)建體積上，作為構(gòu)建工具業(yè)界霸主，webpack一直不停的優(yōu)化構(gòu)建打包流程。通過對舊有項(xiàng)目的優(yōu)化也可以對webpack這個(gè)工具以及性能優(yōu)化的知識(shí)有更深的了解。

轉(zhuǎn)載請注明出處 https://blog.csdn.net/yuanyan...