Vue包大小優化的實現(從1.72M到94K)

Posted on by

一、背景

最近做瞭一個網站，uidea，是用來輔助獨立開發者做一些 UI 設計的，當時隻管開發，等部署完以後，發現訪問速度堪憂
畢竟是個小水管服務器，相比提高帶寬，還是先看看代碼上能不能優化一下，性價比更高
這個是優化前的包大小，這傢夥都上 1.72 M 瞭，小水管加載時間直接往 3s 以上走瞭，臣妾扛不住啊

二、目標

這必須得優化一下，優化前得大致定一下目標，目標又需要指標來衡量，所以定瞭兩個指標：

  • 頁面加載時間不多說，至少得 1s 以內，越快越好
  • 包大小控制在 200k 以內

為什麼定這兩個目標呢？首先頁面加載時間是最終要解決的問題，那頁面加載時間初步來看，影響因素有兩個，網絡和包大小，網絡暫時缺錢沒法升級，所以主要優化就集中在包大小上
首先要定義什麼是包大小，我這裡主要指入口包大小，對應 Vue 就是 app.js 和 app.css，入口加載完頁面至少可以展示瞭

那包大小要優化到什麼程度呢？

一方面 vue-cli-service 建議不超過 244K，另一方面就是找對標，看看類似的網站包大小多少，那我們也有個參照，我選擇的是 materialpalette，看瞭下他的包大小大概在 150k 左右，我的功能更復雜一些，所以取瞭兩者中間的 200K 作為目標

這裡為什麼要講目標呢？因為目標其實是很重要的，老話也說有的放矢，沒有目標，那執行的過程中很容易半途而廢，或者隻前進半步就終止瞭

拿談戀愛來說，如果你的目標是找個女朋友，那大概率找不到，但是如果你的目標是追到某個確定的女生（比如張三）做女朋友，那成功的概率就大大增加瞭，因為你可以去針對這個女生去做針對性的準備

三、方案

目標定瞭，然後就是定方案

雖然咱第一次做 Web 的優化，但是之前有過安卓包大小優化的經驗呀，道理總是相通的，所以第一時間想瞭下面幾個策略

  1. 代碼混淆
  2. 資源放到 cdn，因為開發的時候圖省事，資源放在 assets 下面，直接 require 引入瞭，這也是一個大頭
  3. 無用庫刪除，功能相近的庫合並，隻用到少部分功能的庫，看看能否自己實現
  4. gzip 壓縮
  5. 第三方庫也放到 cdn

1 – 3 三個優化方案是首先想到的，然後網上搜瞭下 Vue 對應的優化策略，又增加瞭後面兩個
還有一些其他方案，比如路由懶加載，但是因為這個網站主要內容都集中在首頁，所以這個就沒考慮瞭（好東西雖多，但因地制宜最好）
所以一共定瞭 5 個優化策略，下面就開幹

四、執行

1. 代碼混淆

代碼混淆就不多說瞭，一方面節省包大小，一方面還能增加一些反編譯的難度，直接網上搜瞭 Vue 混淆配置（畢竟要站在巨人肩膀上），試瞭下確實好使，配置如下 

const CompressionWebpackPlugin = require('compression-webpack-plugin');
module.exports = {
 configureWebpack: (config) => {
  // 引入uglifyjs-webpack-plugin
  let UglifyPlugin = require('uglifyjs-webpack-plugin');

  if (process.env.NODE_ENV == 'production') {
   // 壓縮混淆
   config.mode = 'production'
   // 將每個依賴包打包成單獨的js文件
   let optimization = {
    minimizer: [new UglifyPlugin({
     uglifyOptions: {
      warnings: false,
      compress: {
       drop_console: true,
       drop_debugger: false,
       pure_funcs: ['console.log']
      }
     }
    })]
   }
   Object.assign(config, {
    optimization
   })
  } else {
   // 為開發環境修改配置
   config.mode = 'development'
}
  }
 }
}

2. 資源放到 cdn

這一步也容易做，資源全部都放到阿裡雲 oss 上，幾分鐘搞定

3. 無用庫刪除

這一步花瞭不少時間，因為開發的時候圖省事，很多庫直接 github 上一搜，yarn add 引入就完事瞭，現在需要細細的再拆分一下

在打包命令後面加 –report 看一下打包的狀態 

yarn build --report

首先是去掉 ElementUi（gzip 壓縮後大約 158k），開發的時候 ElementUi 和 Vuetify 混用瞭，其實隻留一個 Vuetify 就夠瞭，然後對界面做一些小小的改造就完成瞭

然後是 lodash，隻用到瞭其中幾個方法，但是他的整個體積不小，gzip 壓縮後大概 25k，於是找瞭 lodash 源碼，打算把用到的幾個方法抽出來，但是 lodash 代碼嵌套、引用太深瞭，不太抽，幹脆直接幹掉這個庫，找瞭幾個更純粹的實現做瞭替換，主要時間花在瞭讀 lodash 源碼上

再然後就是 vuescroll，在實現滾動條樣式自定義的時候，偷懶直接用瞭這個庫，發現這個庫體積還是不小的，gzip 壓縮後將近 20k，直接幹掉，自己寫一下樣式吧（這件事告訴我們，現在偷的懶，以後會以別的方式還回來的 0_0）
這樣就幹掉瞭幾個大頭庫

4. gzip 壓縮

這個是網上找的解決方案，直接在 vue.config.js 裡加點配置，然後 nginx 裡也需要做一下對應的配置 

// vue.config.js
module.exports = {
 configureWebpack: (config) => {
  if (process.env.NODE_ENV == 'production') {
   // ...
   // gzip
   config.plugins.push(new CompressionWebpackPlugin({
    algorithm: 'gzip',
    test: /\.js$|\.html$|\.json$|\.css/,
    threshold: 10240,
    minRatio: 0.8
   }))
  }
  // ...
 }
}
// nginx 直接開啟下面的配置
gzip_static on;

這樣打包以後，會生成 .gz 文件，nginx 會自動使用 .gz 文件

5. 第三方庫放到 cdn

這裡主要是處理 Vuetify 這個庫，畢竟 gzip 以後也有將近 50k 的大小，放到 cdn 上會快一些
首先是打包配置中去掉 Vuetify 

module.exports = {
 // ...
 configureWebpack: (config) => {
  if (process.env.NODE_ENV == 'production') {
   // 第三方庫不打包，使用 cdn
   config.externals = {
    vuetify: 'Vuetify'
   }
  } else {
   // 為開發環境修改配置
   config.mode = 'development'
   config.externals = {
    vuetify: 'Vuetify'
   }
  }
 }
}

然後在 index.html 裡手動加載 vuetify css 和 js 

<link href="https://cdn.staticfile.org/vuetify/2.4.4/vuetify.min.css" rel="external nofollow" rel="stylesheet">
<script src="https://cdn.staticfile.org/vuetify/2.4.4/vuetify.min.js"></script>

這裡其實有一些更好的方式，可以通過 webpack 參數傳給 index.html，通過 ejs 引入，現在比較簡單，這裡就沒做瞭

五、效果

通過上面幾個策略，最終包大小從 1.72 M 優化到 94k

六、後續

總體看來，優化效果是明顯的，但是還有後續可以做的事情：

  • 更精細化優化，應該可以結合 webpack 做更深的定制化
  • 對上面說到的 cdn 上的第三方庫做整合，畢竟直接放在 index.html 裡太散，並不是很好的項目結構，也不利於後面開發
  • 對後續的代碼開發做規范，比如三方庫引用的規范、資源的引入規范等等，可以做的事情還是很多的
  • 每次部署前的性能測試，主要看看頁面加載速度是否達標

可以做的事情還很多，有時候做一件事，達成目標並沒有結束，維持目標也是需要考慮的

到此這篇關於Vue包大小優化的實現(從1.72M到94K)的文章就介紹到這瞭,更多相關Vue包大小優化內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：