這篇文章主要介紹了關於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增加體積為百分之二十;
一張10KB的圖片透過http請求下載為0.2s,他轉為base64之後為12KB,在js下載中,增加了12KB的大小,所以增加0.12S 所以轉base64能優化0.08s的頁面載入速度;
一張100KB的圖片透過http請求的速度是1.1s。轉base64之後大小為120KB,他會增加js的大小120KB,所以增加載入時間1.2s。這樣一算下來,轉為base64之後,並不能優化頁面載入速度,反而拖慢了0.1s的載入速度,為不划算。
思考:
在開發過程中,處理載入速度之外我們還得考慮並行下載的問題。如果全在一個js中,這個js沒下載完成之前,圖片也是沒有下載的,也就是轉base64之後,可以認為js和圖片是串列下載的。而走http請求,圖片是可以跟js並行下載的。所以其實需要更小的圖片才能更划算
以上就是本文的全部內容,希望對大家的學習有所幫助,更多相關內容請關注PHP中文網!
相關推薦:
##
以上是如何解決關於Vue背景圖打包之後訪問路徑錯誤的問題的詳細內容。更多資訊請關注PHP中文網其他相關文章!

Python更適合初學者,學習曲線平緩,語法簡潔;JavaScript適合前端開發,學習曲線較陡,語法靈活。 1.Python語法直觀,適用於數據科學和後端開發。 2.JavaScript靈活,廣泛用於前端和服務器端編程。

Python和JavaScript在社區、庫和資源方面的對比各有優劣。 1)Python社區友好,適合初學者,但前端開發資源不如JavaScript豐富。 2)Python在數據科學和機器學習庫方面強大,JavaScript則在前端開發庫和框架上更勝一籌。 3)兩者的學習資源都豐富,但Python適合從官方文檔開始,JavaScript則以MDNWebDocs為佳。選擇應基於項目需求和個人興趣。

從C/C 轉向JavaScript需要適應動態類型、垃圾回收和異步編程等特點。 1)C/C 是靜態類型語言,需手動管理內存,而JavaScript是動態類型,垃圾回收自動處理。 2)C/C 需編譯成機器碼,JavaScript則為解釋型語言。 3)JavaScript引入閉包、原型鍊和Promise等概念,增強了靈活性和異步編程能力。

不同JavaScript引擎在解析和執行JavaScript代碼時,效果會有所不同,因為每個引擎的實現原理和優化策略各有差異。 1.詞法分析:將源碼轉換為詞法單元。 2.語法分析:生成抽象語法樹。 3.優化和編譯:通過JIT編譯器生成機器碼。 4.執行:運行機器碼。 V8引擎通過即時編譯和隱藏類優化,SpiderMonkey使用類型推斷系統,導致在相同代碼上的性能表現不同。

JavaScript在現實世界中的應用包括服務器端編程、移動應用開發和物聯網控制:1.通過Node.js實現服務器端編程,適用於高並發請求處理。 2.通過ReactNative進行移動應用開發,支持跨平台部署。 3.通過Johnny-Five庫用於物聯網設備控制,適用於硬件交互。

我使用您的日常技術工具構建了功能性的多租戶SaaS應用程序(一個Edtech應用程序),您可以做同樣的事情。 首先,什麼是多租戶SaaS應用程序? 多租戶SaaS應用程序可讓您從唱歌中為多個客戶提供服務

本文展示了與許可證確保的後端的前端集成,並使用Next.js構建功能性Edtech SaaS應用程序。 前端獲取用戶權限以控制UI的可見性並確保API要求遵守角色庫

JavaScript是現代Web開發的核心語言,因其多樣性和靈活性而廣泛應用。 1)前端開發:通過DOM操作和現代框架(如React、Vue.js、Angular)構建動態網頁和單頁面應用。 2)服務器端開發:Node.js利用非阻塞I/O模型處理高並發和實時應用。 3)移動和桌面應用開發:通過ReactNative和Electron實現跨平台開發,提高開發效率。


熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

AI Hentai Generator
免費產生 AI 無盡。

熱門文章

熱工具

SAP NetWeaver Server Adapter for Eclipse
將Eclipse與SAP NetWeaver應用伺服器整合。

Dreamweaver CS6
視覺化網頁開發工具

禪工作室 13.0.1
強大的PHP整合開發環境

EditPlus 中文破解版
體積小,語法高亮,不支援程式碼提示功能

MinGW - Minimalist GNU for Windows
這個專案正在遷移到osdn.net/projects/mingw的過程中,你可以繼續在那裡關注我們。 MinGW:GNU編譯器集合(GCC)的本機Windows移植版本,可自由分發的導入函式庫和用於建置本機Windows應用程式的頭檔;包括對MSVC執行時間的擴展,以支援C99功能。 MinGW的所有軟體都可以在64位元Windows平台上運作。