目錄

• 前言
• 為什么要優化
• 從哪里開始下手
• 現在開始
• 1.代碼壓縮
• 2.刪除一些廢棄的頁面
• 3.使用 cdn 優化
• 4.修改路由引入方式
• 結果

前言

“這頁面加載也太慢了！”，一個寧靜的下午就此打破，在老板和 PM 的 威逼利誘之下 ，我開始了對這個祖傳(shi)山項目進行了優化，因為這個項目傳到我手上至少經過了4-5代前端了，很多東西也不敢隨意刪，找不到負責人。

為什么要優化？

我們主要看首屏加載速度，在測試環境我們項目其實跑得還是蠻快，但是生產環境是用印尼比較差的服務器，再加上需要 kexue 上網（總是網絡出現波動），在這次 UI 2.0 上線之后，堆積的東西終于越來越多，項目也越來越龐大。毫不夸張的說我們現在使用 4G 首次打開頁面的速度大概在 16 秒以上，根據下面的表格推斷出客戶流失率，可是在印尼還在用著 3G 網絡，可想而知這流失率太恐怖了。并且這是一個 C 端產品，所以要更加考慮用戶體驗了

客戶等待頁面時長的流失率

作為一個開發者，你對首頁打開速度又有多高的要求呢？

從哪里開始下手

在觀察了這個項目架構之后呢，我推斷出以下幾個可行方案

對于代碼打包進行壓縮

廢除以前不該用到的組件及頁面

使用 CDN 引入部分資源

優化路由，修改引入方式

對于這幾個優化方案，也是試了一遍又一遍。確實是效果挺大的才發出來給大家圍觀一下

現在開始

記住這張圖中三個比較大的文件 size, 我們每進行一步方案就看看效果

1.代碼壓縮

代碼壓縮是一個很不錯選擇，我們首先需要下載一些依賴

css 代碼壓縮 (optimize-css-assets-webpack-plugin)

下載

npm install optimize-css-assets-webpack-plugin

webpack.config.js 使用

const OptimizeCSSPlugin = require('optimize-css-assets-webpack-plugin'); plugins: [new OptimizeCSSPlugin() ]

js 代碼壓縮 (uglifyjs-webpack-plugin)

下載

npm install optimize-css-assets-webpack-plugin

webpack.config.js 使用

const UglifyJsPlugin = require('uglifyjs-webpack-plugin') plugins:[new UglifyJsPlugin({cache: true, // 開啟緩存parallel: true, // 開啟多線程編譯sourceMap: true, // 是否sourceMapuglifyOptions: { // 丑化參數comments: false,warnings: false,compress: {unused: true,dead_code: true,collapse_vars: true,reduce_vars: true},output: {comments: false}}}), ]

開啟gzip

安裝

npm install compression-webpack-plugin

webpack.config.js 使用

const CompressionWebpackPlugin = require('compression-webpack-plugin') plugins:[new CompressionWebpackPlugin({asset: '[path].gz[query]',algorithm: 'gzip',test: new RegExp('.(' +['js', 'css'].join('|') +')$'),threshold: 10240,minRatio: 0.8}) ]

nginx 配置

gzip on; gzip_static on; gzip_min_length 1k; gzip_buffers 4 32k; gzip_http_version 1.1; gzip_comp_level 2; gzip_types text/plain application/x-javascript text/css application/xml; gzip_vary on; gzip_disable "MSIE [1-6].";

先看看效果

我們在第一步就差不多減少了 1/2 的大小

接著往下看

2.刪除一些廢棄的頁面

這個項目因為之前是一直迭代過來的，在前面也有講到，但是我還是下定決心刪除它們，在截取了一系列屏之后，我找到了老員工 與 PM 來確認頁面是否已經廢棄，這個環境比較費時間，這下面的表格就是一個個確認出來的

在刪除這些路由之后我重新進行了打包，請看下面，還是有點效果的嘛，但這并沒有達到我的預期效果

3. 使用cdn開始性能優化

我們當前使用了 mint ui 庫，vue 全家桶 一系列玩意，我們找到對應的 cdn 在index.html中引入

<script src="https://cdn.bootcdn.net/ajax/libs/vue/3.0.2/vue.cjs.js"></script> <script src="https://cdn.bootcdn.net/ajax/libs/mint-ui/2.2.9/actionsheet/index.js"></script> <script src="https://cdn.bootcdn.net/ajax/libs/axios/0.21.0/axios.js"></script> <script src="https://cdn.bootcdn.net/ajax/libs/vue-router/3.4.8/vue-router.common.js"></script> <script src="https://cdn.bootcdn.net/ajax/libs/vue-i18n/8.22.1/vue-i18n.common.js"></script>

引入完之后呢？將不需要打包的資源進行相應的配置，所以我們需要在 webpack.config.js 中寫上

externals:{'vue':'Vue','mint-ui':'MINT','axios':'axios','vue-router':'VueRouter','vue-i18n':'VueI18n', },

這樣就可以用來忽略這些資源了

4.修改路由引入方式

老嚴將頁面的組件（去除之前刪除的頁面）數了一下是 73個，一般使用 import 引入的寫法，當項目打包時路由里的所有 component 都會打包在一個js中，在項目剛進入首頁的時候，就會加載所有的組件，所以導致首頁加載較慢

import 引入

import DetailActivityStatic from '@/components/discover/share/DetailActivityStatic'export default [{path: "/discover/DetailActivityStatic",component: DetailActivityStatic} ]

現在老嚴全部改為 使用 require

export default [{path: "/discover/DetailActivityStatic",component: resolve => require(['@/components/discover/share/DetailActivityStatic'], resolve)} ]

這個環節也有點累，因為頁面實在太多了，下面是打包后的效果

我們驚奇的發現 js確實小了挺多，那么這些這些內容去哪了？我們也沒有刪除啊

在js文件夾中，我們發現了好多個單個js，這是為什么呢？

因為用 require 會將 component 分別打包成不同的js，按需加載，訪問此路由時才會加載這個js，所以就避免進入首頁時加載內容過多。

所噶，到此為止我們優化做完了。我們來看看效果吧!

結果

來看看效果吧！

有些仔細的朋友會發現，這個app.js 與 vendor.js 怎么會變得比剛剛還小呢？

因為我們得第一步壓縮代碼里面做了 gzip 壓縮

現在首屏打開基本上控制在 1-3s 左右浮動了

相比之前的 16s 簡直不要強太多，PM 與 老板 直呼 “這也太快了！啊啊啊~”

總結

以上是生活随笔為你收集整理的删除vue打包大小限制_如何优化 Vue 祖传代码的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。