How to solve the problem of incorrect access path after Vue background image is packaged

This article mainly introduces the solution to the problem of access path error after Vue background image is packaged. The content is quite good. I will share it with you now and give it as a reference.

Case environment

Vue project created through vue-cli scaffolding

I encountered the problem of background image path error when packaging the project. After After some searching on Google, I found that the problem was caused by the image size limit being too small during configuration.

First of all, the error point lies in the 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]')
}

Here is the explanation of the above url-loader configuration. test is a regular matching rule, matching all formats ending with regular rules in the project Files, to put it bluntly, are all pictures (png, jpg, jpeg, gif, svg). Then use url-loader for processing. There is also a rule for processing as follows. When a file no larger than 10000B is base64 transcoded, the image is converted into base64 format. If the image exceeds 10KB, it will be packaged separately in the directory utils.assetsPath('img/[name].[hash:7].[ext]') (you can know this from build/utils.js and config/index.js The path is the static/img directory, and the image name is the value after hashing. There is no static directory under the root directory, so a static directory will be created. As for why we did not see this directory in the end, we will talk about it later). When we create such a directory After that, all the image access paths become the corresponding static/img/'picture name'. At this point, it can be determined that if pictures smaller than 10KB are converted to base64, and pictures larger than 10KB have the picture path changed to static/img/'picture name', then we will continue to clarify the access path.

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

We know that img is an html tag, and its path is accessed starting from index.html. It can go to static/img/'picture name' The image is accessed correctly, so the path of img is OK. Then app.css accesses static/img/'picture name' incorrectly because there is no static directory in the css directory. This caused the problem of path access failure.

Solution

1. Use small pictures as background pictures (recommendation):

Use pictures smaller than 10KB as background pictures. If there is a picture larger than 10KB as an img picture.

2. Modify the limit value of url-loader (not recommended):

From the above analysis, it can be seen that when the image is converted to base64, there will be no path error problem, ensuring your own background This error can be prevented by converting all images to base64. Change the limit value to the larger value of your largest background image. Convert it to B units

3. Don’t change the css Package it separately (not recommended):

Package it into js directly through css-loader and style-loader, and js automatically creates the style tag. In this way, the access path to the background image is through the index.html path Visited, but this solution is not recommended. It will cause js to be too large, and it is not recommended to convert to base64 for the same reason as pictures that are too large.

4. Use the absolute path of the image address path (recommendation)

Recommendation: Use small pictures as background pictures, and use img tags for large pictures. First of all, we must clarify some differences between background pictures and image img. As far as everyone understands, background pictures are used to modify web pages. For things that have nothing to do with the actual content, use background pictures. If anything related to content should use the img tag, it counts as the content of the web page structure. The modified pictures should be as small as possible, and you can also use image compression and other strategies to reduce the size of the pictures.

Not recommended: The reason why it is not recommended to modify the limit value is that the configuration of url-loader is for the images of the entire project. Modifying the limit value also means that the images with the img tag in the HTML will also be converted to base64. , and the disadvantage of converting to base64 is that it will increase the original size of the image. If you convert a large image to base64, it will cause your js file to be too large, which will increase the time it takes to load js.

About base64

Advantages: base64 is an image represented by a string of string codes. It is loaded together when loading the page or js, reducing image references. A single http request. Students who understand web-side performance optimization know that each http request will take a certain amount of time to establish. For small image requests, the http request establishment time may be longer than the image download itself. Therefore, base64 transcoding of small images is a means to optimize http requests and ensure accelerated page rendering.

Disadvantages: The disadvantage of base64 is as mentioned before. It will increase the size of the image itself. For small images, the increase in size resulting in the increase in js requests can completely make up for the establishment time of one more http request. This The trade-off is cost-effective. But for big pictures, this trade-off is not worthwhile.

Give an example

Example: (The following data are all simulated casually, just take a look at the idea)
If the http creation time is 0.1s each time, the network The transmission is 100KB/s, and the volume increases by 20% each time it is converted to base64;

1. A 10KB picture is downloaded through an http request in 0.2s. After it is converted to base64, it is 12KB, in the js download, the size is increased by 12KB, so it is increased by 0.12S, so converting to base64 can optimize the page loading speed of 0.08s;

2. The request speed of a 100KB image through http is 1.1s. After converting to base64, the size is 120KB, which will increase the size of js by 120KB, so the loading time will be increased by 1.2s. Calculated in this way, after converting to base64, the page loading speed cannot be optimized, but the loading speed is slowed down by 0.1s, which is not cost-effective.

Thinking:

During the development process, in addition to dealing with loading speed, we also have to consider the issue of parallel downloading. If they are all in one js, the pictures will not be downloaded until the js is downloaded. That is, after converting to base64, it can be considered that the js and pictures are downloaded serially. With http requests, images can be downloaded in parallel with js. So in fact, smaller pictures are needed to be more cost-effective

The above is the entire content of this article. I hope it will be helpful to everyone's learning. For more related content, please pay attention to the PHP Chinese website!

Related recommendations:

Introduction to the construction, packaging and publishing process of vue projects

v-for in vue Loading local static image method

vue Implementation of cropping images and uploading them to the server Function introduction

The above is the detailed content of How to solve the problem of incorrect access path after Vue background image is packaged. For more information, please follow other related articles on the PHP Chinese website!