關(guān)于Vue背景圖打包之后訪問(wèn)路徑錯(cuò)誤問(wèn)題的解決

案例環(huán)境

通過(guò)vue-cli腳手架創(chuàng)建的vue項(xiàng)目

在項(xiàng)目打包的時(shí)候遇到了背景圖片路徑出錯(cuò)的問(wèn)題，經(jīng)過(guò)谷歌一番，發(fā)現(xiàn)是在配置的時(shí)候?qū)D片的限制大小過(guò)小造成的

首先，出錯(cuò)點(diǎn)在url-loader上面。

// url-loader配置
// build/webpck.base.conf.js
{
 test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
 loader: 'url-loader',
 query: {
 limit: 10000,
 name: utils.assetsPath('img/[name].[hash:7].[ext]')
}

這里解釋一下上面這段url-loader配置，test是正則匹配規(guī)則，匹配項(xiàng)目中所有的以正則規(guī)則結(jié)尾的格式的文件，直白點(diǎn)就是所以的圖片（png，jpg，jpeg，gif，svg）。然后用url-loader進(jìn)行處理。處理也有個(gè)規(guī)則如下，當(dāng)不大于10000B的文件進(jìn)行base64轉(zhuǎn)碼，就是將圖片轉(zhuǎn)為base64的格式。如果超過(guò)10KB的圖片就單獨(dú)打包到utils.assetsPath(‘img/[name].[hash:7].[ext]') 這個(gè)目錄下（從build/utils.js和config/index.js可以知道這個(gè)路徑就是static/img目錄，并且圖片名是進(jìn)行hash之后的值，根目錄下面沒(méi)有static目錄，所以會(huì)創(chuàng)建一個(gè)static目錄，至于為什么最后沒(méi)有看見(jiàn)這個(gè)目錄后續(xù)再說(shuō)）,當(dāng)我們創(chuàng)建了一個(gè)這樣的目錄之后，所以的圖片訪問(wèn)路徑就成了對(duì)應(yīng)的static/img/'圖片名'。到這里就可以確定，如果小于10KB的圖片轉(zhuǎn)為base64，大于10KB的圖片已經(jīng)將圖片路徑改為了static/img/'圖片名'，然后我們繼續(xù)來(lái)理清訪問(wèn)路徑的事情。

// 目前我們的目錄結(jié)構(gòu)
index.html
static
 |--img
 |--'picname'
 |--css
 |--app.css
 |--js
 |--app.js

我們知道img為html標(biāo)簽，他的路徑是由index.html開(kāi)始訪問(wèn)的，他走static/img/'圖片名'是能正確訪問(wèn)到圖片的，所以img的路徑?jīng)]問(wèn)題，然后app.css訪問(wèn)static/img/'圖片名'是訪問(wèn)錯(cuò)誤的，因?yàn)樵赾ss目錄下并沒(méi)有static目錄。這樣就造成了路徑訪問(wèn)失敗的問(wèn)題。

解決辦法

1、使用小圖片作為背景圖片（建議）：

將小于10KB的圖片作為背景圖片，如果有大于10KB的圖片作為img圖片。

2、修改url-loader的limit值（不建議）：

從上面分析可知，當(dāng)圖片轉(zhuǎn)為base64就沒(méi)有路徑錯(cuò)誤的問(wèn)題，保證自己的背景圖片都能轉(zhuǎn)為base64就可以防止該錯(cuò)誤發(fā)生,將limit的值改為你的背景圖最大那一張的值還大一點(diǎn)就行，換算為B的單位

3、將css不要單獨(dú)打包出來(lái)（不建議）：

直接通過(guò)css-loader和style-loader打包到j(luò)s中，js自動(dòng)創(chuàng)建style標(biāo)簽，這樣，背景圖片的訪問(wèn)路徑就是通過(guò)index.html路徑訪問(wèn)了，不過(guò)該解決方案也不建議。會(huì)導(dǎo)致js過(guò)大，和圖片過(guò)大不建議轉(zhuǎn)base64一個(gè)道理。

4、使用絕對(duì)路徑的圖片地址路徑（建議）

建議：使用小圖片作為背景圖片，大圖片用img標(biāo)簽。首先得分清背景圖片和圖片img的一些區(qū)別，就各人理解而言，背景圖片是用來(lái)修飾網(wǎng)頁(yè)的，與實(shí)際內(nèi)容無(wú)關(guān)的東西，使用背景圖片。如果與內(nèi)容有關(guān)的東西都應(yīng)該使用img標(biāo)簽算作網(wǎng)頁(yè)結(jié)構(gòu)的內(nèi)容。修飾的圖片盡量的小，也可以使用圖片壓縮等策略減小圖片大小。

不建議：不建議修改limit值的原因是，url-loader的配置是針對(duì)整個(gè)項(xiàng)目的圖片，修改了limit值也等于讓html中img標(biāo)簽的圖片也跟著進(jìn)行了base64的轉(zhuǎn)換，而對(duì)于base64的轉(zhuǎn)換的缺點(diǎn)是他會(huì)增大圖片原本的體積，如果對(duì)大圖進(jìn)行了轉(zhuǎn)base64會(huì)造成你的js文件過(guò)大，從而增加了加載js時(shí)間過(guò)長(zhǎng)。

關(guān)于base64

優(yōu)點(diǎn)：base64就是一串字符串碼來(lái)表示的圖片，在加載頁(yè)面或者js的時(shí)候就一并加載過(guò)來(lái)，減少圖片引用時(shí)單獨(dú)的一次http請(qǐng)求。了解web端性能優(yōu)化的同學(xué)都知道，http請(qǐng)求每次建立都會(huì)占用一定的時(shí)間，對(duì)于小圖請(qǐng)求來(lái)說(shuō)，可能http建立請(qǐng)求的時(shí)間比圖片下載本身還長(zhǎng)。所以對(duì)小圖進(jìn)行base64轉(zhuǎn)碼是優(yōu)化http請(qǐng)求，保證頁(yè)面加速渲染的一種手段。

缺點(diǎn)：base64缺點(diǎn)就是之前提到的，他會(huì)增加圖片本身的大小，對(duì)小圖片來(lái)說(shuō)，增加大小導(dǎo)致js的請(qǐng)求增長(zhǎng)完全能彌補(bǔ)多一個(gè)http請(qǐng)求的建立的時(shí)長(zhǎng)，這種取舍是劃算的?？墒菍?duì)于大圖來(lái)說(shuō)，這樣的取舍是不劃算的。

舉個(gè)例子

例子：（以下數(shù)據(jù)都是隨便模擬，看看思路就行）
假如每次建立http時(shí)長(zhǎng)為0.1s，網(wǎng)絡(luò)傳輸為100KB/s，每次轉(zhuǎn)base64增加體積為百分之二十；

1. 一張10KB的圖片通過(guò)http請(qǐng)求下載為0.2s，他轉(zhuǎn)為base64之后為12KB，在js下載中，增加了12KB的大小，所以增加0.12S 所以轉(zhuǎn)base64能優(yōu)化0.08s的頁(yè)面加載速度；
2. 一張100KB的圖片通過(guò)http請(qǐng)求的速度是1.1s。轉(zhuǎn)base64之后大小為120KB，他會(huì)增加js的大小120KB，所以增加加載時(shí)間1.2s。這樣一算下來(lái)，轉(zhuǎn)為base64之后，并不能優(yōu)化頁(yè)面加載速度，反而拖慢了0.1s的加載速度，為不劃算。

思考：

在開(kāi)發(fā)過(guò)程中，處理加載速度之外我們還得考慮并行下載的問(wèn)題。如果全在一個(gè)js中，這個(gè)js沒(méi)下載完成之前，圖片也是沒(méi)有下載的，也就是轉(zhuǎn)base64之后，可以認(rèn)為js和圖片是串行下載的。而走h(yuǎn)ttp請(qǐng)求，圖片是可以和js并行下載的。所以實(shí)際上需要更小的圖片才能更劃算

聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com