Vue項目如何部署？實戰教你

前言

使用vue、react、angular等技術開發過程當中，咱們都會遇到如下問題：

1. 首屏加載慢
2. 每一次更新都須要清除瀏覽器緩存才能看到效果(常常被測試吐槽)

這兩個問題能夠從不少方面進行優化，今天我就從前端頁面部署階段來優化一下這兩個問題。PS：如下內容都基於vue-cli3+。
         3.光理論是不夠的。在此贈送2020最新企業級 Vue3.0/Js/ES6/TS/React/node等實戰視頻教程，想學的可進裙 519293536 免費獲取，小白勿進哦！

前端頁面文件緩存方案

從vue-cli3打包提及

路由使用按需加載後，打包生成的文件，每個路由頁面都對應一個js和css文件，入口main.js及其依賴則打包成了app.js和app.css，公共依賴都放到了chunk-vendors.js。

vue-cli3打包後的dist/js文件夾：

 

 

能夠看到，打包生成的js/css/img等文件的文件名都帶有hash值，當源文件內容改變時，從新打包後對應的文件hash值也會改變。舉個栗子，咱們修改了about.vue中js的內容，從新打包時about.js的hash值會改變，以及依賴about.vue的文件app.js的hash值也會改變，而其餘沒有修改的文件，打包後的hash值都不會改變。

咱們知道，文件名帶hash是爲了消除緩存帶來的影響的，可是全部文件都不緩存確定不是一個很好的解決方案。

vue-cli3打包生成的文件名帶hash值的做用

爲了緩存的最優體驗

咱們先來簡單回顧下http緩存的知識(參考MDN)：

1. HTTP1.0 是經過Expires（文件過時時間）和Last-Modified（最近修改時間）來告訴瀏覽器進行緩存的，這兩個字段都是 UTC 時間（絕對時間）。Expires 過時控制不穩定，由於瀏覽器端能夠隨意修改本地時間，致使緩存使用不精準。並且 Last-Modified 過時時間只能精確到秒。
2. HTTP1.1 經過Cache-Contorl和 Etag（版本號）進行緩存控制。瀏覽器先檢查 Cache-Control，若是有，則以 Cache-Control 爲準，忽略 Expires。若是沒有 Cache-Control，則以 Expires 爲準。

Cache-Control 除了能夠設置 max-age（相對過時時間，以秒爲單位）之外，還能夠設置以下幾種經常使用值:

• public，資源容許被中間服務器緩存。瀏覽器請求服務器時，若是緩存時間沒到，中間服務器直接返回給瀏覽器內容，而沒必要請求源服務器。
• private，資源不容許被中間代理服務器緩存。瀏覽器請求服務器時，中間服務器都要把瀏覽器的請求透傳給服務器。
• no-cache，無論本地副本是否過時，每次訪問資源，瀏覽器都要向服務器詢問，若是文件沒變化，服務器只告訴瀏覽器繼續使用緩存（304）。
• no-store，瀏覽器和中間代理服務器都不能緩存資源。每次訪問資源，瀏覽器都必須請求服務器，而且，服務器不去檢查文件是否變化，而是直接返回完整的資源。
• must-revalidate，本地副本過時前，可使用本地副本；本地副本一旦過時，必須去源服務器進行有效性校驗。
• proxy-revalidate，要求代理服務器針對緩存資源向源服務器進行確認。
• s-maxage：緩存服務器對資源緩存的最大時間。

如今99%的瀏覽器都是HTTP1.1及以上版本，咱們配置緩存就使用Cache-Contorl和Etag配合就行了。

那麼問題來了，檢查文件是否最新不是用etag嗎，爲何文件名還須要有hash值？

（1）若是文件名不帶hash值，文件版本得用etag來標記，瀏覽器須要先去檢查下是否過時，服務器則須要檢查文件是否最新。

（2）而文件名帶有hash值，能夠直接將文件的過時時間設置爲1年，瀏覽器就不用檢查是否過時，直接使用。

緣由是，若是頁面源文件有修改，生成的js/css的hash值就會修改，對應的請求js/css地址也會變化，htpp地址改了，也就不用檢查是否過時。沒修改的文件的hash則不變，可使用緩存文件。

因此利用文件名帶hash來作緩存，即能保證，頁面有修改瀏覽器能請求到最新的文件，又能節省服務器的請求（檢查是否過時的請求）。

實現無感知發版

只有一臺服務器的狀況下，咱們的頁面文件須要更新，一般操做是：先刪掉舊文件，而後上傳新文件，這段時間系統將不可用，對用戶有必定的影響。

僅更新前端頁面的前提下，文件名帶有hash值還能夠實現用戶無感知發版：系統更新時，只須要將打包以後的文件除index.html之外的文件（js/css/img），所有上傳到服務器網站目錄，未修改文件（即重名文件）直接跳過，有修改的文件因爲文件的hash值不一樣會被上傳，上傳完畢咱們再將index.html覆蓋掉舊版就行。這段時間用戶已請求舊版本index.html的無影響（不會出現文件404，由於新舊版本js/css同時存在），而新訪問用戶則請求的是新版index.html，訪問舊頁面用戶刷新也會請求新版文件，而且無緩存影響，即對用戶使用0影響。一段時間以後，咱們只須要按文件生成時間對比一下刪除舊文件便可。PS：替換前端文件不須要重啓服務器。

總結： 凡是文件名帶有hash值的的文件均可以設置爲「永久緩存」（一年），其餘不帶hash的文件使用etag來設置緩存，由Nginx判斷是否過時。

優化打包結果

頁面部署的時候，有個問題，如何區分文件名是否帶有hash值呢？正則匹配顯然不是很好的辦法。其實辦法很簡單，打包生成的文件都帶有hash值，而public目錄裏面的文件不會通過打包處理。因此只須要將public目錄裏面的文件除了index.html所有放到一個static目錄（注意引入路徑）

 

 

那麼打包後的文件目錄就會變成這樣：

 

 

static目錄裏面的文件和index.html的文件名是不帶hash值的，其餘的文件都是帶有hash值的

補充：打包後發現一些頁面文件很小，只有幾K

以下圖所示，雖然是按需加載，可是感受浪費服務器請求

 

 

這時，咱們能夠配置webpack的特殊註釋(須要 Webpack > 2.4)，將一些按需加載的路由打包到同一個js文件

const Foo = () => import(/* webpackChunkName: "group-foo" */ './Foo.vue')const Bar = () => import(/* webpackChunkName: "group-foo" */ './Bar.vue')const Baz = () => import(/* webpackChunkName: "group-foo" */ './Baz.vue')複製代碼

這裏須要注意一下，雖然每一個文件單獨打包都是1k，可是1k+1k不等於2k，也就是說，打包到一塊兒的體積會比原來分開的大，4個1k的文件打包到一塊兒，體積大約是10k，體積達到10k,恰好就會觸發gzip壓縮，壓縮以後體積在4k左右，因此並無什麼影響。

服務器配置緩存

理論知識有了，如今咱們來實際操做一下：文件名帶hash的(即css、js、font和img目錄下的全部文件)設置一個月緩存，瀏覽器能夠直接使用緩存不須要請求服務器。其餘的文件（index.html和static目錄下的文件）設置爲no-cache，即每次都來服務器檢查是否最新。

爲何緩存時間是一個月，剛纔不是說設置一年？設置爲一年，固然沒有任何問題。不變的文件能夠一直使用，有改動的文件，會從新請求，可是有該動的舊文件已經沒有用了，因爲過時時間是一年，因此不會被刪的，一直佔用用戶的硬盤，系統更新越頻繁，無用舊文件越多，佔用的存儲也越多，這樣是很差的（用戶看了想打人）。因此設置一個合理的時間比較好，一個月就挺好。

廢話不說，以Nginx服務器爲例，配置以下（配置文件nginx.conf的http模塊）：

server {
  location = /index.html {
     add_header Cache-Control no-cache;
  }

  location ~ /static/ {
     add_header Cache-Control no-cache;
  }

  location ~ /(js/*|css/*|img/*|font/*) {
      expires 30d;
      add_header Cache-Control public;
   }
}複製代碼

效果以下圖：當咱們修改index.html內容時，會從新請求，沒有修改就會304，文件名帶hash的都是直接從本地緩存讀取。

 

 

有兩點須要注意的地方：

1. 項目裏面不要用service-worker，這會影響咱們的緩存設置，瀏覽器會優先使用service-worker緩存。vue-cli4的pwa插件生成的模板自帶service-worker

 

 

 

 

1. 調試的時候記得容許緩存

 

 

前端文件設置gzip壓縮

webpack配置生成gzip壓縮的文件

webpack有一個文件壓縮的插件，能夠將大文件壓縮成gzip的格式。使用起來也很是簡單，先安裝：npm install --save-dev compression-webpack-plugin，

而後修改webpack配置（vue.config.js）：

const CompressionWebpackPlugin = require("compression-webpack-plugin");// 可加入須要的其餘文件類型，好比json// 圖片不要壓縮，體積會比原來還大const productionGzipExtensions = ["js", "css"];module.exports = {  configureWebpack: config => {    if (process.env.NODE_ENV === "production"){      return {        plugins: [          new CompressionWebpackPlugin({            // filename: '[path].gz[query]',
            algorithm: "gzip",            test: new RegExp("\\.(" + productionGzipExtensions.join("|") + ")$"),            threshold: 10240, //對超過10k的數據進行壓縮
            minRatio: 0.6 // 壓縮比例，值爲0 ~ 1
          })
        ]
      };
    }
  }
};複製代碼

打包完的js/css文件，都會多一份對應的gzip文件，部署的時候須要配置一下，啓用gzip，這樣支持gzip壓縮的瀏覽器請求的就是壓縮文件，不支持的瀏覽器請求的就是源文件，gzip壓縮文件體積會小不少。

 

 

字體文件是否須要gzip？

網站中常見的圖片的格式有jpg(jpeg)、png、gif、webp，這些格式的圖片自己已經優化了，因此再也不須要gzip。實際上對圖片進行gzip壓縮，不只沒有效果，反而可能使圖片體積更大。那麼字體文件呢，是否是和圖片同樣？

從阿里巴巴矢量圖庫生成的圖標字體的css中咱們能夠看出，通常常見的字體文件有：eot、woff、ttf、svg，另外woff2是以base64的格式存儲的。

@font-face {font-family: "iconfont";  src: url('iconfont.eot?t=1587624344896'), /* IE9 */  url('iconfont.woff?t=1587624344896') format('woff'),  url('data:application/x-font-woff2;charset=utf-8;base64,...') format('woff2'),  url('iconfont.ttf?t=1587624344896') format('truetype'), /* chrome, firefox, opera, Safari, Android, iOS 4.2+ */  url('iconfont.svg?t=1587624344896#iconfont') format('svg'); /* iOS 4.1- */
}複製代碼

查閱資料後發現：eot 和 ttf 格式通常狀況下自己不壓縮，也就是說能夠進行gzip壓縮。而woff格式具備內建壓縮，不須要gzip壓縮。

實際測試一下，發現eot和ttf能夠進行壓縮，效果還不錯，而woff格式的，CompressionWebpackPlugin插件根本不支持壓縮，即便你寫了配置了壓縮woff文件，它也不會生成gz文件。

 

 

而且實驗發現,svg雖然是圖片，可是也能夠進行gzip壓縮，壓縮效果還不錯：

 

 

結論：svg、eot 和 ttf 這三種格式的字體文件可使用CompressionWebpackPlugin進行壓縮，而且配合Nginx的gzip_types配置，woff和woff2格式的字體文件不須要gzip。

服務器配置gzip壓縮

Nginx是前端文件經常使用的服務器，Nginx服務器的配置文件nginx.conf的http模塊：

server {
  # 開啓gzip on爲開啓，off爲關閉
  gzip on;
  # 檢查是否存在請求靜態文件的gz結尾的文件，若是有則直接返回該gz文件內容，不存在則先壓縮再返回
  gzip_static on;
  # 設置容許壓縮的頁面最小字節數，頁面字節數從header頭中的Content-Length中進行獲取。
  # 默認值是0，無論頁面多大都壓縮。
  # 建議設置成大於10k的字節數，配合compression-webpack-plugin
  gzip_min_length 10k;
  # 對特定的MIME類型生效,其中'text/html’被系統強制啓用
  gzip_types text/javascript application/javascript text/css application/json;
  # Nginx做爲反向代理的時候啓用，開啓或者關閉後端服務器返回的結果
  # 匹配的前提是後端服務器必需要返回包含"Via"的 header頭
  # off(關閉全部代理結果的數據的壓縮)
  # expired(啓用壓縮,若是header頭中包括"Expires"頭信息)
  # no-cache(啓用壓縮,header頭中包含"Cache-Control:no-cache")
  # no-store(啓用壓縮,header頭中包含"Cache-Control:no-store")
  # private(啓用壓縮,header頭中包含"Cache-Control:private")
  # no_last_modefied(啓用壓縮,header頭中不包含"Last-Modified")
  # no_etag(啓用壓縮,若是header頭中不包含"Etag"頭信息)
  # auth(啓用壓縮,若是header頭中包含"Authorization"頭信息)
  # any - 無條件啓用壓縮
  gzip_proxied any;
  # 請求加個 vary頭，給代理服務器用的，有的瀏覽器支持壓縮，有的不支持，因此避免浪費不支持的也壓縮
  gzip_vary on;
  # 同 compression-webpack-plugin 插件同樣，gzip壓縮比（1~9），
  # 越小壓縮效果越差，可是越大處理越慢，通常取中間值
  gzip_comp_level 6;
  # 獲取多少內存用於緩存壓縮結果，‘16  8k’表示以8k*16 爲單位得到。
  # PS: 若是沒有.gz文件，是須要Nginx實時壓縮的
  gzip_buffers 16 8k;
  # 注：99.99%的瀏覽器基本上都支持gzip解壓了，因此能夠不用設這個值,保持系統默認便可。
  gzip_http_version 1.1; 
}複製代碼

檢查gzip是否生效

瀏覽器文件請求的請求頭包含字段Accept-Encoding: gzip表明瀏覽器支持gzip壓縮文件

 

 

文件響應頭包含字段Content-Encoding: gzip表明返回的是壓縮文件

 

 

同時NetWork一欄還能夠查看到文件的實際大小和實際的請求（gzip）文件大小

 

 

檢查Nginx是否使用了咱們提供的gz文件

Nginx自帶gzip壓縮功能，若是咱們沒提供，它會實時壓縮（例如index.html文件），這就很浪費服務器資源了。如今咱們已經提供js和css的gz文件，如何判斷Nginx是使用了咱們提供的gz文件，而不是本身壓縮的呢？

上面有一個配置項：gzip_static on;，開啓以後Nginx會優先使用咱們的gz文件，可是仍是不能肯定，Nginx有沒有使用gz文件。

查看network請求發現，每個文件都有etag響應頭，若是Nginx使用了已有的gz文件，那麼這個請求的etag值不帶有W/，反之，若是是文件是Nginx壓縮的，etag值則會帶有W/。

例如index.html:

 

 

拿chunk-vendors.js作一個實驗，這個文件自己是帶有gz文件的，請求的etag以下（不帶有W/）：

 

 

這時候咱們刪掉服務器上chunk-vendors.js對應的gz文件，刷新頁面，請求以下：

 

 

綜上，咱們就能夠驗證，只要咱們配置了gzip_static on;，Nginx就會優先使用了咱們提供的gz文件。

附錄 - windows安裝Nginx服務器

1. 下載windows下Nginx的安裝包：nginx.org/en/download…

 

 

1. 解壓壓縮包

 

 

1. 在Nginx的目錄下使用cmd命令行，啓動命令：start nginx，關閉命令：nginx -s stop

備註：修改配置文件須要重載配置：nginx -s reload。啓動以後，打開http://localhost:80就能看的效果

總結

1.頁面文件合理的設置緩存和gzip壓縮是實實在在能提高用戶體驗的操做，並且比少寫幾個循環、刪除幾行代碼優化強得多，可是須要前端和運維的密切配合，才能實現最佳方案。

service worker是用來實現離線應用的，文章中沒有詳細贅述。vue-cli4的pwa插件生成的模板自帶service worker，或許這纔是vue項目緩存的最佳實踐？