Comment résoudre le problème du chemin d'accès incorrect après le conditionnement de l'image d'arrière-plan Vue

Cet article présente principalement la solution au problème de l'erreur de chemin d'accès après le packaging de l'image d'arrière-plan Vue. Le contenu est assez bon, je vais le partager avec vous maintenant et le donner comme référence.

Environnement de cas

Le projet vue créé via l'échafaudage vue-cli

a rencontré le problème de l'erreur de chemin de l'image d'arrière-plan lors de l'empaquetage du projet. quelques recherches sur Google, j'ai découvert que cela était dû à une limite de taille d'image trop petite lors de la configuration

Tout d'abord, le point d'erreur était dans le chargeur d'URL.

// 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]')
}

Voici l'explication de la configuration du chargeur d'URL ci-dessus qui est une règle de correspondance régulière. Tous les éléments correspondants se terminent par des règles normales. . Les fichiers au format, pour parler franchement, sont tous des images (png, jpg, jpeg, gif, svg). Utilisez ensuite le chargeur d'URL pour le traitement. Il existe également une règle de traitement comme suit. Lorsqu'un fichier ne dépassant pas 10 000 B est transcodé en base64, l'image est convertie au format base64. Si l'image dépasse 10 Ko, elle sera emballée séparément dans le répertoire utils.assetsPath('img/[name].[hash:7].[ext]') (vous pouvez le savoir à partir de build/utils.js et config/ index.js Le chemin est le répertoire static/img et le nom de l'image est la valeur après hachage. Il n'y a pas de répertoire statique sous le répertoire racine, donc un répertoire statique sera créé. Quant à savoir pourquoi nous n'avons pas vu ce répertoire dans. la fin, nous en reparlerons plus tard). Lorsque nous créons un tel répertoire. Après cela, tous les chemins d'accès aux images deviennent le static/img/'picture name' correspondant. À ce stade, il peut être déterminé que si les images inférieures à 10 Ko sont converties en base64 et que le chemin de l'image des images supérieures à 10 Ko est modifié en static/img/'picture name', nous continuerons à clarifier le chemin d'accès.

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

Nous savons que img est une balise HTML, et son chemin est accessible à partir de index.html Il va vers static/img/'picture. name' L'image est accessible correctement, donc le chemin de img est OK. Ensuite, lorsque app.css accède à static/img/'image name', c'est une erreur d'accès car il n'y a pas de répertoire statique dans le répertoire css. Cela a provoqué le problème de l’échec de l’accès au chemin.

Solution

1. Utilisez de petites images comme images d'arrière-plan (recommandation) :

Utilisez des images inférieures à 10 Ko comme images d'arrière-plan. il y a une image de plus de 10 Ko comme image img.

2. Modifier la valeur limite de url-loader (non recommandé) :

D'après l'analyse ci-dessus, on peut voir que lorsque l'image est convertie en base64, il y aura il n'y aura pas de problème d'erreur de chemin, garantissant votre propre arrière-plan. Cette erreur peut être évitée en convertissant toutes les images en base64. Modifiez la valeur limite par la valeur la plus grande de votre plus grande image d'arrière-plan et convertissez-la en unité de B

. 3. Supprimez le package css séparément (non recommandé) :

est empaqueté directement dans js via css-loader et style-loader, et js crée automatiquement la balise de style de cette manière, l'accès. le chemin d'accès à l'image d'arrière-plan se fait via le chemin index.html visité, mais cette solution n'est pas recommandée. Cela rendrait les fichiers js trop grands et il n'est pas recommandé de les convertir en base64 pour la même raison que les images trop grandes.

4. Utilisez des chemins absolus pour les chemins d'adresse des images (recommandation)

Suggestion : utilisez de petites images comme images d'arrière-plan et utilisez des balises img pour les grandes images. Tout d'abord, nous devons clarifier certaines différences entre les images d'arrière-plan et l'image img. Pour autant que tout le monde le comprenne, les images d'arrière-plan sont utilisées pour modifier les pages Web. Pour des choses qui n'ont rien à voir avec le contenu réel, utilisez des images d'arrière-plan. Si quelque chose lié au contenu doit utiliser la balise img, cela compte comme le contenu de la structure de la page Web. Les images modifiées doivent être aussi petites que possible et vous pouvez également utiliser la compression d'image et d'autres stratégies pour réduire la taille des images.

Non recommandé : La raison pour laquelle il n'est pas recommandé de modifier la valeur limite est que la configuration de url-loader concerne les images de l'ensemble du projet. La modification de la valeur limite signifie également que les images avec l'img. La balise HTML sera également convertie en base64, et l'inconvénient de la conversion en base64 est qu'elle augmentera la taille d'origine de l'image. Si vous convertissez une grande image en base64, votre fichier js sera trop volumineux. , ce qui augmentera le temps nécessaire au chargement de js.

À propos de base64

Avantages : base64 est une image représentée par une chaîne de codes de chaîne Elle est chargée ensemble lors du chargement de la page ou du js, réduisant ainsi les références d'image A. requête http unique. Les étudiants qui comprennent l'optimisation des performances côté Web savent que l'établissement de chaque requête http prendra un certain temps. Pour les petites requêtes d'image, le temps d'établissement de la requête http peut être plus long que le téléchargement de l'image elle-même. Par conséquent, le transcodage base64 de petites images est un moyen d’optimiser les requêtes http et d’assurer un rendu accéléré des pages.

Inconvénients : L'inconvénient du base64 est comme mentionné précédemment. Il va augmenter la taille de l'image elle-même, l'augmentation de la taille entraînant une augmentation des requêtes js peut compenser complètement le temps d'établissement. d'une requête http supplémentaire. Ce compromis est rentable. Mais pour les grandes images, ce compromis n’en vaut pas la peine.

Donnez un exemple

Exemple : (Les données suivantes sont toutes simulées avec désinvolture, jetez simplement un œil à l'idée)
Si le temps de création http est de 0,1 s à chaque fois, le réseau La transmission est de 100 Ko/s, et le volume augmente de 20 % à chaque fois qu'il est converti en base64

1. Une image de 10 Ko est téléchargée via une requête http dans 0,2 s. Après sa conversion en base64, il fait 12 Ko, dans le téléchargement js, la taille est augmentée de 12 Ko, elle est donc augmentée de 0,12 S, donc la conversion en base64 peut optimiser la vitesse de chargement de la page de

2. La vitesse de requête d'une image de 100 Ko via http est de 1,1 s. Après la conversion en base64, la taille est de 120 Ko, ce qui augmentera la taille de js de 120 Ko, donc le temps de chargement sera augmenté de 1,2 s. Calculée de cette manière, après conversion en base64, la vitesse de chargement des pages ne peut pas être optimisée, mais la vitesse de chargement est ralentie de 0,1 s, ce qui n'est pas rentable.

Réflexion :

Pendant le processus de développement, en plus de traiter de la vitesse de chargement, nous devons également considérer la question de téléchargement parallèle. S'ils sont tous dans un seul js, les images ne seront pas téléchargées tant que le js n'est pas téléchargé. Autrement dit, après la conversion en base64, on peut considérer que les js et les images sont téléchargés en série. Avec les requêtes http, les images peuvent être téléchargées en parallèle avec js. Donc en fait, des images plus petites sont nécessaires pour être plus rentables

Ce qui précède est l'intégralité du contenu de cet article. J'espère qu'il sera utile à l'apprentissage de chacun. Pour plus de contenu connexe, veuillez prêter attention au. Site Web chinois PHP !

Recommandations associées :

Introduction au processus de construction, de packaging et de publication des projets vue

v-for in vue Méthode de chargement d'image statique locale

Vue implémente la fonction de recadrage des images et de les télécharger sur le serveur

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!