vue項(xiàng)目部署的最佳實(shí)踐
前言
使用vue、react、angular等技術(shù)開(kāi)發(fā)過(guò)程中，我們都會(huì)遇到以下問(wèn)題：
首屏加載慢
每一次更新都需要清除瀏覽器緩存才能看到效果(經(jīng)常被測(cè)試吐槽)
這兩個(gè)問(wèn)題可以從很多方面進(jìn)行優(yōu)化，今天我就從前端頁(yè)面部署階段來(lái)優(yōu)化一下這兩個(gè)問(wèn)題。PS：以下內(nèi)容都基于vue-cli3+。
前端頁(yè)面文件緩存方案
從vue-cli3打包說(shuō)起
路由使用按需加載后，打包生成的文件，每一個(gè)路由頁(yè)面都對(duì)應(yīng)一個(gè)js和css文件，入口main.js及其依賴(lài)則打包成了app.js和app.css，公共依賴(lài)都放到了chunk-vendors.js。
vue-cli3打包后的dist/js文件夾：
可以看到，打包生成的js/css/img等文件的文件名都帶有hash值，當(dāng)源文件內(nèi)容改變時(shí)，重新打包后對(duì)應(yīng)的文件hash值也會(huì)改變。舉個(gè)栗子，我們修改了about.vue中js的內(nèi)容，重新打包時(shí)about.js的hash值會(huì)改變，以及依賴(lài)about.vue的文件app.js的hash值也會(huì)改變，而其他沒(méi)有修改的文件，打包后的hash值都不會(huì)改變。
我們知道，文件名帶hash是為了消除緩存帶來(lái)的影響的，但是所有文件都不緩存肯定不是一個(gè)很好的解決方案。
vue-cli3打包生成的文件名帶hash值的作用
為了緩存的最優(yōu)體驗(yàn)
我們先來(lái)簡(jiǎn)單回顧下http緩存的知識(shí)(參考MDN：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Caching_FAQ)：
HTTP1.0?是通過(guò)Expires（文件過(guò)期時(shí)間）和Last-Modified（最近修改時(shí)間）來(lái)告訴瀏覽器進(jìn)行緩存的，這兩個(gè)字段都是?UTC?時(shí)間（絕對(duì)時(shí)間）。Expires?過(guò)期控制不穩(wěn)定，因?yàn)闉g覽器端可以隨意修改本地時(shí)間，導(dǎo)致緩存使用不精準(zhǔn)。而且?Last-Modified?過(guò)期時(shí)間只能精確到秒。HTTP1.1?通過(guò)Cache-Contorl和?Etag（版本號(hào)）進(jìn)行緩存控制。瀏覽器先檢查?Cache-Control，如果有，則以?Cache-Control?為準(zhǔn)，忽略?Expires。如果沒(méi)有?Cache-Control，則以?Expires?為準(zhǔn)。
Cache-Control?除了可以設(shè)置?max-age（相對(duì)過(guò)期時(shí)間，以秒為單位）以外，還可以設(shè)置如下幾種常用值:
public，資源允許被中間服務(wù)器緩存。瀏覽器請(qǐng)求服務(wù)器時(shí)，如果緩存時(shí)間沒(méi)到，中間服務(wù)器直接返回給瀏覽器內(nèi)容，而不必請(qǐng)求源服務(wù)器。private，資源不允許被中間代理服務(wù)器緩存。瀏覽器請(qǐng)求服務(wù)器時(shí)，中間服務(wù)器都要把瀏覽器的請(qǐng)求透?jìng)鹘o服務(wù)器。no-cache，不管本地副本是否過(guò)期，每次訪問(wèn)資源，瀏覽器都要向服務(wù)器詢(xún)問(wèn)，如果文件沒(méi)變化，服務(wù)器只告訴瀏覽器繼續(xù)使用緩存（304）。no-store，瀏覽器和中間代理服務(wù)器都不能緩存資源。每次訪問(wèn)資源，瀏覽器都必須請(qǐng)求服務(wù)器，并且，服務(wù)器不去檢查文件是否變化，而是直接返回完整的資源。must-revalidate，本地副本過(guò)期前，可以使用本地副本；本地副本一旦過(guò)期，必須去源服務(wù)器進(jìn)行有效性校驗(yàn)。proxy-revalidate，要求代理服務(wù)器針對(duì)緩存資源向源服務(wù)器進(jìn)行確認(rèn)。s-maxage：緩存服務(wù)器對(duì)資源緩存的最大時(shí)間。
現(xiàn)在99%的瀏覽器都是HTTP1.1及以上版本，我們配置緩存就使用Cache-Contorl和Etag配合就好了。
那么問(wèn)題來(lái)了，檢查文件是否最新不是用etag嗎，為什么文件名還需要有hash值？
（1）如果文件名不帶hash值，文件版本得用etag來(lái)標(biāo)記，瀏覽器需要先去檢查下是否過(guò)期，服務(wù)器則需要檢查文件是否最新。
（2）而文件名帶有hash值，可以直接將文件的過(guò)期時(shí)間設(shè)置為1年，瀏覽器就不用檢查是否過(guò)期，直接使用。
原因是，如果頁(yè)面源文件有修改，生成的js/css的hash值就會(huì)修改，對(duì)應(yīng)的請(qǐng)求js/css地址也會(huì)變化，htpp地址改了，也就不用檢查是否過(guò)期。沒(méi)修改的文件的hash則不變，可以使用緩存文件。
所以利用文件名帶hash來(lái)做緩存，即能保證，頁(yè)面有修改瀏覽器能請(qǐng)求到最新的文件，又能節(jié)省服務(wù)器的請(qǐng)求（檢查是否過(guò)期的請(qǐng)求）。
實(shí)現(xiàn)無(wú)感知發(fā)版
只有一臺(tái)服務(wù)器的情況下，我們的頁(yè)面文件需要更新，通常操作是：先刪掉舊文件，然后上傳新文件，這段時(shí)間系統(tǒng)將不可用，對(duì)用戶有一定的影響。
僅更新前端頁(yè)面的前提下，文件名帶有hash值還可以實(shí)現(xiàn)用戶無(wú)感知發(fā)版：系統(tǒng)更新時(shí)，只需要將打包之后的文件除index.html以外的文件（js/css/img），全部上傳到服務(wù)器網(wǎng)站目錄，未修改文件（即重名文件）直接跳過(guò)，有修改的文件由于文件的hash值不同會(huì)被上傳，上傳完畢我們?cè)賹?code style="padding: 0.065em 0.4em;max-width: 100%;font-family: Menlo, Monaco, Consolas, Courier New, monospace;font-size: 0.87em;word-break: break-word;color: rgb(255, 80, 44);background-color: rgb(255, 245, 245);border-radius: 2px;overflow-x: auto;box-sizing: border-box !important;overflow-wrap: break-word !important;">index.html覆蓋掉舊版就行。這段時(shí)間用戶已請(qǐng)求舊版本index.html的無(wú)影響（不會(huì)出現(xiàn)文件404，因?yàn)樾屡f版本js/css同時(shí)存在），而新訪問(wèn)用戶則請(qǐng)求的是新版index.html，訪問(wèn)舊頁(yè)面用戶刷新也會(huì)請(qǐng)求新版文件，并且無(wú)緩存影響，即對(duì)用戶使用0影響。一段時(shí)間之后，我們只需要按文件生成時(shí)間對(duì)比一下刪除舊文件即可。PS：替換前端文件不需要重啟服務(wù)器。
總結(jié)：?凡是文件名帶有hash值的的文件都可以設(shè)置為“永久緩存”（一年），其他不帶hash的文件使用etag來(lái)設(shè)置緩存，由Nginx判斷是否過(guò)期。
優(yōu)化打包結(jié)果
頁(yè)面部署的時(shí)候，有個(gè)問(wèn)題，如何區(qū)分文件名是否帶有hash值呢？正則匹配顯然不是很好的辦法。其實(shí)辦法很簡(jiǎn)單，打包生成的文件都帶有hash值，而public目錄里面的文件不會(huì)經(jīng)過(guò)打包處理。所以只需要將public目錄里面的文件除了index.html全部放到一個(gè)static目錄（注意引入路徑）
那么打包后的文件目錄就會(huì)變成這樣：
static目錄里面的文件和index.html的文件名是不帶hash值的，其他的文件都是帶有hash值的
補(bǔ)充：打包后發(fā)現(xiàn)一些頁(yè)面文件很小，只有幾K
如下圖所示，雖然是按需加載，但是感覺(jué)浪費(fèi)服務(wù)器請(qǐng)求
這時(shí)，我們可以配置webpack的特殊注釋(需要?Webpack?> 2.4)，將一些按需加載的路由打包到同一個(gè)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')這里需要注意一下，雖然每個(gè)文件單獨(dú)打包都是1k，但是1k+1k不等于2k，也就是說(shuō)，打包到一起的體積會(huì)比原來(lái)分開(kāi)的大，4個(gè)1k的文件打包到一起，體積大約是10k，體積達(dá)到10k,剛好就會(huì)觸發(fā)gzip壓縮，壓縮之后體積在4k左右，所以并沒(méi)有什么影響。
服務(wù)器配置緩存
理論知識(shí)有了，現(xiàn)在我們來(lái)實(shí)際操作一下：文件名帶hash的(即css、js、font和img目錄下的所有文件)設(shè)置一個(gè)月緩存，瀏覽器可以直接使用緩存不需要請(qǐng)求服務(wù)器。其他的文件（index.html和static目錄下的文件）設(shè)置為no-cache，即每次都來(lái)服務(wù)器檢查是否最新。
為什么緩存時(shí)間是一個(gè)月，剛才不是說(shuō)設(shè)置一年？設(shè)置為一年，當(dāng)然沒(méi)有任何問(wèn)題。不變的文件可以一直使用，有改動(dòng)的文件，會(huì)重新請(qǐng)求，但是有該動(dòng)的舊文件已經(jīng)沒(méi)有用了，由于過(guò)期時(shí)間是一年，所以不會(huì)被刪的，一直占用用戶的硬盤(pán)，系統(tǒng)更新越頻繁，無(wú)用舊文件越多，占用的存儲(chǔ)也越多，這樣是不好的（用戶看了想打人）。所以設(shè)置一個(gè)合理的時(shí)間比較好，一個(gè)月就挺好。
廢話不說(shuō)，以Nginx服務(wù)器為例，配置如下（配置文件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;
}
}效果如下圖：當(dāng)我們修改index.html內(nèi)容時(shí)，會(huì)重新請(qǐng)求，沒(méi)有修改就會(huì)304，文件名帶hash的都是直接從本地緩存讀取。
有兩點(diǎn)需要注意的地方：
項(xiàng)目里面不要用
service-worker，這會(huì)影響我們的緩存設(shè)置，瀏覽器會(huì)優(yōu)先使用service-worker緩存。vue-cli4生成的模板自帶service-worker
調(diào)試的時(shí)候記得允許緩存
前端文件設(shè)置gzip壓縮
webpack配置生成gzip壓縮的文件
webpack有一個(gè)文件壓縮的插件，可以將大文件壓縮成gzip的格式。使用起來(lái)也非常簡(jiǎn)單，先安裝：npm install --save-dev compression-webpack-plugin，
然后修改webpack配置（vue.config.js）：
const CompressionWebpackPlugin = require("compression-webpack-plugin");
// 可加入需要的其他文件類(lèi)型，比如json
// 圖片不要壓縮，體積會(huì)比原來(lái)還大
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, //對(duì)超過(guò)10k的數(shù)據(jù)進(jìn)行壓縮
minRatio: 0.6 // 壓縮比例，值為0 ~ 1
})
]
};
}
}
};打包完的js/css文件，都會(huì)多一份對(duì)應(yīng)的gzip文件，部署的時(shí)候需要配置一下，啟用gzip，這樣支持gzip壓縮的瀏覽器請(qǐng)求的就是壓縮文件，不支持的瀏覽器請(qǐng)求的就是源文件，gzip壓縮文件體積會(huì)小很多。
字體文件是否需要gzip？
網(wǎng)站中常見(jiàn)的圖片的格式有jpg(jpeg)、png、gif、webp，這些格式的圖片本身已經(jīng)優(yōu)化了，所以不再需要gzip。實(shí)際上對(duì)圖片進(jìn)行gzip壓縮，不僅沒(méi)有效果，反而可能使圖片體積更大。那么字體文件呢，是不是和圖片一樣？
從阿里巴巴矢量圖庫(kù)生成的圖標(biāo)字體的css中我們可以看出，一般常見(jiàn)的字體文件有：eot、woff、ttf、svg，另外woff2是以base64的格式存儲(chǔ)的。
@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- */
}查閱資料后發(fā)現(xiàn)：eot?和?ttf?格式一般情況下本身不壓縮，也就是說(shuō)可以進(jìn)行gzip壓縮。而woff格式具有內(nèi)建壓縮，不需要gzip壓縮。
實(shí)際測(cè)試一下，發(fā)現(xiàn)eot和ttf可以進(jìn)行壓縮，效果還不錯(cuò)，而woff格式的，CompressionWebpackPlugin插件根本不支持壓縮，即使你寫(xiě)了配置了壓縮woff文件，它也不會(huì)生成gz文件。
并且實(shí)驗(yàn)發(fā)現(xiàn),svg雖然是圖片，但是也可以進(jìn)行gzip壓縮，壓縮效果還不錯(cuò)：
結(jié)論：svg、eot?和?ttf?這三種格式的字體文件可以使用CompressionWebpackPlugin進(jìn)行壓縮，并且配合Nginx的gzip_types配置，woff和woff2格式的字體文件不需要gzip。
服務(wù)器配置gzip壓縮
Nginx是前端文件常用的服務(wù)器，Nginx服務(wù)器的配置文件nginx.conf的http模塊：
server {
# 開(kāi)啟gzip on為開(kāi)啟，off為關(guān)閉
gzip on;
# 檢查是否存在請(qǐng)求靜態(tài)文件的gz結(jié)尾的文件，如果有則直接返回該gz文件內(nèi)容，不存在則先壓縮再返回
gzip_static on;
# 設(shè)置允許壓縮的頁(yè)面最小字節(jié)數(shù)，頁(yè)面字節(jié)數(shù)從header頭中的Content-Length中進(jìn)行獲取。
# 默認(rèn)值是0，不管頁(yè)面多大都?jí)嚎s。
# 建議設(shè)置成大于10k的字節(jié)數(shù)，配合compression-webpack-plugin
gzip_min_length 10k;
# 對(duì)特定的MIME類(lèi)型生效,其中'text/html’被系統(tǒng)強(qiáng)制啟用
gzip_types text/javascript application/javascript text/css application/json;
# Nginx作為反向代理的時(shí)候啟用，開(kāi)啟或者關(guān)閉后端服務(wù)器返回的結(jié)果
# 匹配的前提是后端服務(wù)器必須要返回包含"Via"的 header頭
# off(關(guān)閉所有代理結(jié)果的數(shù)據(jù)的壓縮)
# 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 - 無(wú)條件啟用壓縮
gzip_proxied any;
# 請(qǐng)求加個(gè) vary頭，給代理服務(wù)器用的，有的瀏覽器支持壓縮，有的不支持，所以避免浪費(fèi)不支持的也壓縮
gzip_vary on;
# 同 compression-webpack-plugin 插件一樣，gzip壓縮比（1~9），
# 越小壓縮效果越差，但是越大處理越慢，一般取中間值
gzip_comp_level 6;
# 獲取多少內(nèi)存用于緩存壓縮結(jié)果，‘16 8k’表示以8k*16 為單位獲得。
# PS: 如果沒(méi)有.gz文件，是需要Nginx實(shí)時(shí)壓縮的
gzip_buffers 16 8k;
# 注：99.99%的瀏覽器基本上都支持gzip解壓了，所以可以不用設(shè)這個(gè)值,保持系統(tǒng)默認(rèn)即可。
gzip_http_version 1.1;
}檢查gzip是否生效
瀏覽器文件請(qǐng)求的請(qǐng)求頭包含字段Accept-Encoding: gzip代表瀏覽器支持gzip壓縮文件
文件響應(yīng)頭包含字段Content-Encoding: gzip代表返回的是壓縮文件
同時(shí)NetWork一欄還可以查看到文件的實(shí)際大小和實(shí)際的請(qǐng)求（gzip）文件大小
檢查Nginx是否使用了我們提供的gz文件
Nginx自帶gzip壓縮功能，如果我們沒(méi)提供，它會(huì)實(shí)時(shí)壓縮（例如index.html文件），這就很浪費(fèi)服務(wù)器資源了?，F(xiàn)在我們已經(jīng)提供js和css的gz文件，如何判斷Nginx是使用了我們提供的gz文件，而不是自己壓縮的呢？
上面有一個(gè)配置項(xiàng)：gzip_static on;，開(kāi)啟之后Nginx會(huì)優(yōu)先使用我們的gz文件，但是還是不能確定，Nginx有沒(méi)有使用gz文件。
查看network請(qǐng)求發(fā)現(xiàn)，每一個(gè)文件都有etag響應(yīng)頭，如果Nginx使用了已有的gz文件，那么這個(gè)請(qǐng)求的etag值不帶有W/，反之，如果是文件是Nginx壓縮的，etag值則會(huì)帶有W/。
例如index.html:
拿chunk-vendors.js做一個(gè)實(shí)驗(yàn)，這個(gè)文件本身是帶有gz文件的，請(qǐng)求的etag如下（不帶有W/）：
這時(shí)候我們刪掉服務(wù)器上chunk-vendors.js對(duì)應(yīng)的gz文件，刷新頁(yè)面，請(qǐng)求如下：
綜上，我們就可以驗(yàn)證，只要我們配置了gzip_static on;，Nginx就會(huì)優(yōu)先使用了我們提供的gz文件。
附錄 -?windows安裝Nginx服務(wù)器
下載
windows下Nginx的安裝包：nginx.org/en/download…
解壓壓縮包
在
Nginx的目錄下使用cmd命令行，啟動(dòng)命令：start nginx，關(guān)閉命令：nginx -s stop
備注：修改配置文件需要重載配置：nginx -s reload。啟動(dòng)之后，打開(kāi)http://localhost:80就能看的效果
總結(jié)
頁(yè)面文件合理的設(shè)置緩存和gzip壓縮是實(shí)實(shí)在在能提升用戶體驗(yàn)的操作，而且比少寫(xiě)幾個(gè)循環(huán)、刪除幾行代碼優(yōu)化強(qiáng)得多，但是需要前端和運(yùn)維的密切配合，才能實(shí)現(xiàn)最佳方案。
service worker是用來(lái)實(shí)現(xiàn)離線應(yīng)用的，文章中沒(méi)有詳細(xì)贅述。vue-cli4生成的模板自帶service worker，或許這才是vue項(xiàng)目緩存的最佳實(shí)踐？
來(lái)源：編程微刊
本文版權(quán)歸原作者所有，如有問(wèn)題請(qǐng)聯(lián)系我刪除。