影響網頁響應速度的因素有很多，例如：http請求次數太多、伺服器本身處理請求太久、請求內容太大、JS指令碼執行耗時過長、瀏覽器迴流重繪等。網站頁面的響應速度與使用者體驗息息相關，直接影響到使用者是否願意繼續訪問你的網站。對於Vue專案而言，最普遍的問題可能在於打包後的檔案太大，導致載入時間過長。

　　我的一個小專案，僅有三四個頁面，但因為伺服器頻寬太小了，載入時間過長的問題尤為明顯，於是採用路由懶載入和gzip壓縮的方式優化了一下，訪問速度得到了顯著提升。

一、路由懶載入：分割程式碼塊

　　Vue支援非同步元件，即可以在使用元件的地方使用一個Promise，Promise最終會通過resolve回傳一個元件物件。而webpack的動態import的方式可以讓程式碼分塊進行打包，並且返回一個Promise（正是非同步元件所需要的）。在路由配置表裡使用import可以將各個頁面元件分割成不同的程式碼塊，然後當路由被訪問的時候才載入對應的元件，這樣就避免將所有內容打包在一個chunk裡，從而“按需載入”，大大提高響應速度。

　　沒有使用動態載入的路由配置方式：

// router.js
import VueRouter from 'vue-router'
import Vue from 'vue'
Vue.use(VueRouter)

import Home from '@/pages/Home'
import Tree from '@/pages/Tree'
import SearchHighlight from '@/pages/SearchHighlight'
import Watermark from '@/pages/Watermark'

export default new VueRouter({
 routes: [
  {
   path: '/',component: Home,children: [
    {
     path: 'tree',name: 'Tree',component: Tree
    },{
     path: 'search-highlight',name: 'SearchHighlight',component: SearchHighlight
    },{
     path: 'watermark',name: 'Watermark',component: Watermark
    }
   ]
  }
 ]
})

　　執行yarn build（或npm run build）打包，檢視dist資料夾下的js和css:

　　可以看到打包後js和css下各有兩個檔案，其中chunk-vendors檔案包含了所有頁面js或者css檔案，大小分別為769K、270K。現在修改路由配置使用動態載入元件的方式打包，來看一下打包的檔案是怎樣的。

　　使用 () => import('xxx')的形式引入元件：

// router.js
import VueRouter from 'vue-router'
import Vue from 'vue'
Vue.use(VueRouter)

export default new VueRouter({
 routes: [
  {
   path: '/',component: () => import('@/pages/Home'),component: () => import('@/pages/Tree')
    },component: () => import('@/pages/SearchHighlight')
    },component: () => import('@/pages/Watermark')
    }
   ]
  }
 ]
})

執行yarn build（或npm run build）打包，檢視dist資料夾下的js和css:

　　js和css資料夾下各多出來了4個chunk-*檔案，剛好對應我們動態引入的4個元件，這樣在我們訪問到某個頁面，才會載入頁面對應的chunk-*.js和chunk-*.css。觀察檔案大小，核心的JS檔案chunk-venders大小從769K降低到了725K，因為我的4個頁面程式碼都非常簡單，看起來優化效果不大，然而在一個頁面很多的大型專案中，優化效果會非常明顯，CSS部分也是如此。

二、壓縮請求資源

1. 原理介紹

　　日常我們在使用網盤的時候，上傳一個很大的資料夾肯定很慢，這時候我們會把它壓縮成一個壓縮包，需要下載的時候下載下來解壓就可以了，這樣大大節省了上傳和下載的時間。同樣的原理可以用於網路請求，當我們向伺服器請求一個資源時，比如js或者css檔案，伺服器將檔案壓縮，然後返回到瀏覽器，瀏覽器操作解壓之後即可使用。

　　首先瀏覽器在傳送請求的時候，會通過請求頭Accept-Encoding告知伺服器，本瀏覽器支援哪些編碼格式的資源。開啟瀏覽器的network，檢視當前網頁的某個請求的請求頭：

　　Accept-Encoding的值表示瀏覽器支援gzip生成的編碼格式或者deflate壓縮演算法生成的編碼格式，這就告訴伺服器，如果可以把該請求的資源用這兩個方法壓縮一下給我也是可以的。Accept-Encoding可能還會有compress壓縮、identity不壓縮的預設格式。

　　如果伺服器對資源進行壓縮編碼了，它就會通過響應頭Content-Encoding告知當前請求用了什麼編碼格式，當然如果伺服器沒幹這事，則不會返回這個響應頭，比如某個請求用gzip壓縮了返回的內容：

2. 伺服器配置

　　一般我們部署到伺服器會使用nginx來做代理伺服器，所有的請求都通過nginx轉發，這裡演示一下nginx配置gzip壓縮檔案後再返回。配置前先看看示例專案釋出到線上的請求情況：

　　可以看到之前生成的chunk-vendors檔案，大小725K，請求時間7.10秒，其中下載時間7.05秒，太慢了。配置一下nginx，開啟gzip:

server {
    gzip on;
    gzip_types text/plain application/javascript application/x-javascript text/javascript text/xml text/css;
}

　　這個配置作用是，當nginx伺服器返回gzip_types中列出的內容型別時，先使用gzip進行壓縮（當然，前提是請求方支援gzip），執行sudo nginx -s reload讓該配置生效，此時重新整理剛才的頁面看一下效果:

　　同樣的一個請求，請求內容的大小變成了216K，而下載時間直接降低到了1s多，效果顯著！nginx還有gzip的其它配置項，比如可以用gzip_comp_level可以控制壓縮率（當然壓縮率更高可能意味著更大的伺服器消耗），有興趣的同學可以檢視nginx文件。

3. webpack打包時直接使用gzip壓縮

　　上一步驟中，返回內容是在請求伺服器的時候使用gzip進行壓縮的。這樣存在的問題時，對於同一個資源的不同請求，反覆壓縮，這無疑會增加伺服器的CPU和記憶體消耗。使用webpack的話，可以直接用compression-webpack-plugin外掛對我們的程式碼進行壓縮。先安裝compression-webpack-plugin到dev依賴：

// yarn安裝
yarn add compression-webpack-plugin -D
// 或npm
npm install compression-webpack-plugin --save-dev

　　簡單配置，更多配置可瞭解官方文件：compression-webpack-plugin:

const CompressionPlugin = require('compression-webpack-plugin')

module.exports = {
 // ...
 configureWebpack: {
  plugins: [
   new CompressionPlugin({
    test: /\.(js|css)?$/i,// 哪些檔案要壓縮
    filename: '[path].gz[query]',　// 壓縮後的檔名
    algorithm: 'gzip',　// 使用gzip壓縮
    minRatio: 1,　// 壓縮率小於1才會壓縮
    deleteOriginalAssets: true // 刪除未壓縮的檔案，謹慎設定，如果希望提供非gzip的資源，可不設定或者設定為false
   })
  ]
 }
}

　　打包一下看看dist下的js和css資料夾，現在檔案都被壓縮成了.gz：

　　經過壓縮之後chunk-vendors僅有176K，比起原始的725K，壓縮了近80%。像圖片、字型之類的也可以用這個方法進行壓縮，只要修改test配置項的正則表示式匹配這類檔案即可。不過現在，還需要在nginx伺服器配置一下靜態壓縮：

server {
  gzip on;
  gzip_types text/plain application/javascript application/x-javascript text/javascript text/xml text/css;
  
  gzip_static on;
}

　　gzip_static設定為on之後，這樣在訪問資源的時候，如果存在“資源路徑.gz”的檔案，則會直接返回該檔案，其優先順序高於動態的gzip。現在訪問一下頁面：

　　如果把滑鼠懸指到chunk-vendors的size上，可以看到提示“176KB transfered over network,resource size: 724K”。如果你的專案出現請求資原始檔太大，可以試試gzip之類的壓縮手段，相信有立竿見影的效果。

　　到此這篇關於Vue專案打包壓縮的實現(讓頁面更快響應)的文章就介紹到這了,更多相關Vue專案打包壓縮內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！