首頁 > web前端 > js教程 > 如何解決關於Vue背景圖打包之後訪問路徑錯誤的問題

如何解決關於Vue背景圖打包之後訪問路徑錯誤的問題

不言
發布: 2018-06-29 15:50:19
原創
1410 人瀏覽過

這篇文章主要介紹了關於Vue背景圖打包之後訪問路徑錯誤問題的解決,內容挺不錯的,現在分享給大家,也給大家做個參考。

案例環境

透過vue-cli腳手架建立的vue專案

在專案打包的時候遇到了背景圖片路徑出錯的問題,經過谷歌一番,發現是在配置的時候對圖片的限制大小過小造成的

#首先,出錯點在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是正規符合規則,符合專案中所有的以正規規則結尾的格式的文件,直白點就是所以的圖片(png,jpg,jpeg,gif,svg)。然後用url-loader進行處理。處理也有個規則如下,當不大於10000B的檔案進行base64轉碼,就是將圖片轉為base64的格式。如果超過10KB的圖片就單獨打包到utils.assetsPath('img/[name].[hash:7].[ext]') 這個目錄下(從build/utils.js和config/index.js可以知道這個路徑就是static/img目錄,而且圖片名是進行hash之後的值,根目錄下面沒有static目錄,所以會創建一個static目錄,至於為什麼最後沒有看見這個目錄後續再說),當我們創建了一個這樣的目錄之後,所以的圖片訪問路徑就成了對應的static/img/'圖片名'。到這裡就可以確定,如果小於10KB的圖片轉為base64,大於10KB的圖片已經將圖片路徑改為了static/img/'圖片名',然後我們繼續來理清訪問路徑的事情。

// 目前我们的目录结构
index.html
static
  |--img
    |--'picname'
  |--css
    |--app.css
  |--js
    |--app.js
登入後複製

我們知道img為html標籤,他的路徑是由index.html開始訪問的,他走static/img/'圖片名'是能正確存取到圖片的,所以img的路徑沒問題,然後app.css存取static/img/'圖片名稱'是存取錯誤的,因為在css目錄下並沒有static目錄。這樣就造成了路徑存取失敗的問題。

解決方法

1、使用小圖片作為背景圖片(建議):

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

2、修改url-loader的limit值(不建議):

從上面分析可知,當圖片轉為base64就沒有路徑錯誤的問題,保證自己的背景圖片都能轉換為base64就可以防止該錯誤發生,將limit的值改為你的背景圖最大那一張的值還大一點就行,換算為B的單位

#3、將css不要單獨打包出來(不建議):

直接透過css-loader和style-loader打包到js中,js自動建立style標籤,這樣,背景圖片的存取路徑就是透過index.html路徑訪問了,不過該解決方案也不建議。會導致js過大,和圖片過大不建議轉base64一個道理。

4、使用絕對路徑的圖片位址路徑(建議)

建議:使用小圖片作為背景圖片,大圖片用img標籤。首先得分清背景圖片和圖片img的一些區別,就各人理解而言,背景圖片是用來修飾網頁的,與實際內容無關的東西,使用背景圖片。如果與內容有關的東西都應該使用img標籤來算作網頁結構的內容。修飾的圖片盡量的小,也可以使用圖片壓縮等策略來減少圖片大小。

不建議:不建議修改limit值的原因是,url-loader的設定是針對整個專案的圖片,修改了limit值也等於讓html中img標籤的圖片也跟著進行了base64的轉換,而對於base64的轉換的缺點是他會增大圖片原本的體積,如果對大圖進行了轉base64會造成你的js檔案過大,從而增加了加載js時間過長。

關於base64

優點:base64就是一串字串碼來表示的圖片,在載入頁面或js的時候就一併載入過來,減少圖片引用時單獨的一次http請求。了解web端效能優化的同學都知道,http請求每次建立都會佔用一定的時間,對於小圖請求來說,可能http建立請求的時間比圖片下載本身還要長。所以對小圖進行base64轉碼是優化http請求,確保頁面加速渲染的一種手段。

缺點:base64缺點就是之前提到的,他會增加圖片本身的大小,對小圖片來說,增加大小導致js的請求增長完全能彌補​​多一個http請求的建立的時長,這種取捨是划算的。可是對於大圖來說,這樣的取捨是不划算的。

舉例

範例:(以下資料都是隨便模擬,看看思路就行)
假如每次建立http時長為0.1s,網絡傳輸為100KB/s,每次轉base64增加體積為百分之二十;

  1. 一張10KB的圖片透過http請求下載為0.2s,他轉為base64之後為12KB,在js下載中,增加了12KB的大小,所以增加0.12S 所以轉base64能優化0.08s的頁面載入速度;

  2. 一張100KB的圖片透過http請求的速度是1.1s。轉base64之後大小為120KB,他會增加js的大小120KB,所以增加載入時間1.2s。這樣一算下來,轉為base64之後,並不能優化頁面載入速度,反而拖慢了0.1s的載入速度,為不划算。

思考:

在開發過程中,處理載入速度之外我們還得考慮並行下載的問題。如果全在一個js中,這個js沒下載完成之前,圖片也是沒有下載的,也就是轉base64之後,可以認為js和圖片是串列下載的。而走http請求,圖片是可以跟js並行下載的。所以其實需要更小的圖片才能更划算

以上就是本文的全部內容,希望對大家的學習有所幫助,更多相關內容請關注PHP中文網!

相關推薦:

關於vue專案的構建,打包和發布過程的介紹

##vue中v-for載入本機靜態圖片方法

vue 實作剪裁圖片並上傳伺服器的功能介紹

##

以上是如何解決關於Vue背景圖打包之後訪問路徑錯誤的問題的詳細內容。更多資訊請關注PHP中文網其他相關文章!

相關標籤:
來源:php.cn
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
作者最新文章
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板