前言

之前用 vuecli 做了個博客，是一個單頁面項目，大概有十個路由，直接 npm run build 打包出來，有一個 1M 的巨大 js 文件

先掛載到服務器上試試

好家伙 這加載時間 仿佛過了半個世紀

首屏頁面整整加載了 9s 光加載那個大文件就花了 8s

這必須得做個優化了，沒有用戶能忍受 9s 的白屏而不關閉頁面的

過程中，我還順便把項目從 vuecli 2.x 遷移到了 vuecli 3，所以接下來還會介紹一些它們在優化上的異同

分析

vuecli 2.x 自帶了分析工具，因此只要運行 npm run build --report 即可。

如果是 vuecli 3 的話，先安裝插件 

cnpm intall webpack bundle analyzer save dev 

然后在 vue.config.js 中對 webpack 進行配置 

chainWebpack: (config) => {  
    /* 添加分析工具*/  
    if (process.env.NODE_ENV === 'production') { 
        if (process.env.npm_config_report) {  
            config  
                .plugin('webpack-bundle-analyzer')  
                .use(require('webpack-bundle-analyzer').BundleAnalyzerPlugin)  
                .end();  
            config.plugins.delete('prefetch')  
        }  
    } } 

再運行 npm run build --report

這時會在瀏覽器打開一個項目打包的情況圖，便于直觀地比較各個  bundle 文件的大小

可以看到，項目中所有的依賴，所有的路由，都被打包進了同一個文件中。

另外，在瀏覽器中，也可以通過 converge 來查看代碼的使用狀況

紅色的是下載了但未使用的部分。

路由懶加載

當打包構建應用時，JavaScript 包會變得非常大，影響頁面加載。如果我們能把不同路由對應的組件分割成不同的代碼塊，然后當路由被訪問的時候才加載對應組件，這樣就更加高效了。

在一開始就下載完所有路由對應的組件文件，這明顯是不合適的，這就像下載一個 app 了，所以我們就需要使用路由懶加載

在 router.js 文件中，原來的靜態引用方式 

import ShowBlogs from '@/components/ShowBlogs'  
routes:[ path: 'Blogs', name: 'ShowBlogs', component: ShowBlogs ] 

改為 

routes:[ path: 'Blogs',name: 'ShowBlogs',component: () => import('./components/ShowBlogs.vue') 

以函數的形式動態引入，這樣就可以把各自的路由文件分別打包，只有在解析給定的路由時，才會下載路由組件

首屏需要加載的文件變成了橙色的部分，被小弟們分流出去了 300k

如果是在 vuecli 3 中，我們還需要多做一步工作因為 vuecli 3 默認開啟 prefetch(預先加載模塊)，提前獲取用戶未來可能會訪問的內容。

在首屏會把這十幾個路由文件，都一口氣下載了所以我們要關閉這個功能，在 vue.config.js 中設置

參考官網的做法：

設置完畢后，首屏就只會加載當前頁面路由的組件了

element-ui按需加載

首屏需要加載的依賴包，其中 element-ui 整整占了 568k

原本的引進方式引進了整個包： 

import ElementUI from 'element-ui'  
Vue.use(ElementUI) 

但實際上我用到的組件只有按鈕，分頁，表格，輸入與警告

所以我們要按需引用： 

import { Button, Input, Pagination, Table, TableColumn, MessageBox } from 'element-ui';  
Vue.use(Button)  
Vue.use(Input)  
Vue.use(Pagination)  
Vue.prototype.$alert = MessageBox.alert 

注意 MessageBox 注冊方法的區別，并且我們雖然用到了 alert，但并不需要引入 Alert 組件

在 .babelrc 文件中添加（vue-cli 3 要先安裝 babel-plugin-component)： 

plugins: [  
    [  
      "component",  
      {  
        "libraryName": "element-ui",  
        "styleLibraryName": "theme-chalk"  
      }  
    ]  
  ] 

element-ui 小了很多，不過看到那個顯眼的 table.js 后想到， table 組件只有后臺管理頁面用到了，不需要全局注冊，所以我們刪除 main.js 中 Table 和 TablColumn 的引用，并在后臺組件中局部注冊 

import { Table, TableColumn } from "element-ui";  
components: {  
    "el-table": Table,  
    "el-table-column": TableColumn }, 

table 就被拆分到了路由文件中

組件重復打包

可以看到上圖，有兩個路由文件都引用了 codemirror.js 造成重復下載。我們可以在 webpack 的 config 文件中，修改 CommonsChunkPlugin 的配置 

minChunks: 3 

把 3 改為 2，就會把使用 2 次及以上的包抽離出來，放進公共依賴文件，不過由于首頁也有復用的組件，所以首頁也會下載這個公共依賴文件

首頁下載了黃色和灰色部分。

拆了半天，又回到原點

當然，我們可以繼續折騰 CommonsChunkPlugin 的配置來解決這個問題。

但在新版 webpack 中， CommonsChunkPlugin 被自由度更高，更高級的 SplitChunksPlugin 代替

這也是為什么我要把項目遷移到 vuecli 3（使用 webpack4）

因為默認就做了優化，首頁只會下載灰色的部分（ 235K）

gzip

拆完包之后，我們再用 gzip 做一下壓縮安裝 compression-webpack-plugin 

cnmp i compression-webpack-plugin -D 

在 vue.congig.js 中引入并修改 webpack 配置 

const CompressionPlugin = require('compression-webpack-plugin')  
configureWebpack: (config) => {  
        if (process.env.NODE_ENV === 'production') {  
            // 為生產環境修改配置...  
            config.mode = 'production'  
            return {  
                plugins: [new CompressionPlugin({  
                    test: /\.js$|\.html$|\.css/, //匹配文件名  
                    threshold: 10240, //對超過10k的數據進行壓縮  
                    deleteOriginalAssets: false //是否刪除原文件  
                })]  
            }  
        } 

可以看到 200k 以上的文件被壓縮到了 100k 以內

在服務器我們也要做相應的配置

如果發送請求的瀏覽器支持 gzip，就發送給它 gzip 格式的文件

我的服務器是用 express 框架搭建的，只要安裝一下 compression 就能使用 

const compression = require('compression')  
app.use(compression()) 

注意，后面這一句，要放在所有其他中間件注冊之前

最終效果

首屏加載資源 198k，加載時間 1s，相比原來速度提升了 90%

后記：css是否要拆分

vuecli 3 和 vuecli2.x 還有一個區別是

•  vuecli 3會默認開啟一個 css 分離插件 ExtractTextPlugin

每一個模塊的 css 文件都會分離出來，整整 13 個 css文件，而我們的首頁就請求了 4 個，花費了不少的資源請求時間。

我們可以在 vue.config.js 中關閉它 

css: {  
    // 是否使用css分離插件 ExtractTextPlugin  
    extract: false,  
    // 開啟 CSS source maps?  
    sourceMap: false,  
    // css預設器配置項  
    loaderOptions: {},  
    // 啟用 CSS modules for all css / pre-processor files.  
    modules: false  
}, 

打包出來的文件中，直接就沒有了 css 文件夾

取而代之的是整合起來的一個 js 文件，負責在一開始就注入所有的樣式。

首屏加載文件數減少，但體積變大，最終測下來速度沒有太大差異。

所以，是否要 css 拆分就見仁見智，具體項目具體分析吧。

總結

性能優化是一個非常令人愉悅的過程，同時也是個深坑，有著太多東西，本篇文章開了個頭，希望能對大家有所幫助。