¿Cómo resolver el problema de la ruta de acceso incorrecta después del empaquetado en segundo plano de Vue?
Entorno del caso
Proyecto Vue creado mediante andamios Vue-cli
Al empaquetar el proyecto, encontré el problema de que la ruta de la imagen de fondo es incorrecta. Después de buscar en Google, descubrí que se debía al tamaño limitado de la imagen durante la configuración.
En primer lugar, el punto de error está en el cargador de URL.
// configuración del cargador de URL
// build/webpck.base.conf.js
{
Prueba:/\ . (png|jpe?g|gif|svg)(\?.*)?$/,
Cargador: "cargador de URL",
Consulta: {
Límite: 10000,
Nombre: utils.assetsPath('img/[nombre]). [Hash:7]. [Extensión]')
}La siguiente es una explicación de la configuración del cargador de URL anterior. La prueba es una regla de coincidencia general que coincide con todos los archivos del proyecto cuyo formato termina con la regla general. Para decirlo sin rodeos, son todas imágenes (png, jpg, jpeg, gif, svg). Luego use el cargador de URL para procesar. Hay otra regla que se procesa de la siguiente manera: cuando se realiza la transcodificación base64 en un archivo que no supera los 10000 B, la imagen se convierte al formato base64. Si la imagen supera los 10 KB, se empaquetará en la ruta del directorio utils.assets ('img/[nombre]). [Hash:7]. [ext]') (Desde build/utils.js y config/index.js, podemos saber que esta ruta es el directorio estático/img y el nombre de la imagen es el valor hash. No hay ningún directorio estático en el directorio raíz , por lo que se creará un directorio estático. En cuanto a por qué no vimos este directorio al final, cuando creamos dicho directorio, la ruta de acceso a la imagen se convirtió en el correspondiente static/img/'nombre de imagen'. que si convierte imágenes de menos de 10 KB a base64, la ruta de la imagen para imágenes de más de 10 KB se ha cambiado a static/img/' nombre de imagen '. A continuación, continuamos aclarando la ruta de acceso. >//Nuestra estructura de directorio actual
Estática
| - img
| /p>
| - css
| - app.css
| - js
|-app.js Sabemos que img es un html etiqueta, y su ruta es visitada por index.html. Es estática. /img/'nombre de imagen' puede acceder correctamente a la imagen, por lo que la ruta de img está bien, pero es incorrecto que app.css acceda a static/img. /'nombre de la imagen', porque no hay un directorio estático en el directorio css, lo que genera un problema de falla en el acceso.
Solución
1. imagen (recomendado):
Utilice una imagen de menos de 10 KB como imagen de fondo, si hay una. Las imágenes de más de 10 KB son imágenes img.
2. -loader (no recomendado):
Del análisis anterior, podemos ver que la conversión de imágenes a base64 es Si no hay un error de ruta, puede evitar este error asegurándose de que todas sus imágenes de fondo se puedan convertir. a base64 simplemente cambie el valor límite al valor de la imagen más grande en su imagen de fondo y conviértalo a la unidad de b
3. >
Empaquételo directamente en js a través de css-loader y style-loader, y js crea automáticamente una etiqueta de estilo para que pueda pasarse a través de la ruta index.html para acceder a la imagen de fondo, pero no se recomienda esta solución.
Hará que js sea demasiado grande y no se recomienda cambiar a base64 si la pantalla es demasiado grande.
4. Utilice la ruta absoluta de la dirección de la imagen (recomendado)
Sugerencia: utilice imágenes pequeñas como imágenes de fondo y utilice etiquetas img para imágenes grandes. Primero, distingamos algunas diferencias entre imágenes de fondo e imágenes img. Como todos entienden, las imágenes de fondo se usan para decorar páginas web y las imágenes de fondo se usan para hacer cosas que no tienen nada que ver con el contenido real. Si todo lo relacionado con el contenido debe contarse como contenido de la estructura de la página web utilizando la etiqueta img. La imagen modificada debe ser lo más pequeña posible y también puede utilizar la compresión de imágenes y otras estrategias para reducir el tamaño de la imagen.
No recomendado: No se recomienda modificar el valor límite porque la configuración de url-loader es para la imagen de todo el proyecto. Modificar el valor límite equivale a la conversión base64 de imágenes marcadas como img en html. La desventaja de la conversión base64 es que aumenta el tamaño original de la imagen. Si convierte imágenes grandes a base64, su archivo js será demasiado grande, lo que aumentará el tiempo de carga de js.
Acerca de base64
Ventajas: base64 es una cadena de imágenes representadas por códigos de cadena, que se cargan cuando se carga la página o js, lo que reduce una sola solicitud http cuando se hace referencia a la imagen. . Los estudiantes que saben cómo optimizar el rendimiento web saben que se necesita una cierta cantidad de tiempo para establecer una solicitud http cada vez. Para solicitudes de miniaturas, configurar la solicitud http puede llevar más tiempo que descargar la imagen en sí. Por lo tanto, la transcodificación de miniaturas en base64 es una forma de optimizar las solicitudes http y garantizar una representación acelerada de la página.
Desventajas: Las desventajas de base64 mencionadas anteriormente son que aumentará el tamaño de la imagen en sí. Para imágenes pequeñas, el aumento de tamaño compensará por completo el tiempo de establecimiento de una solicitud http más, y esta compensación es rentable. Pero por el bien común, el sacrificio no vale la pena.
Por ejemplo
Ejemplo: (Los siguientes datos son simulaciones aleatorias, solo mire las ideas)
Si el tiempo de establecimiento de http es 0,1 s, la red la transmisión es de 100 KB/s, luego, cada vez que se transmite base64, el volumen aumentará en un 20%;
Se descarga una imagen de 10 KB a través de una solicitud http en 0,08 s y, después de convertirla a base64, se 12 KB. En la descarga js, el tamaño aumentó en 12 KB, por lo que aumentó en 0,12 S, por lo que la velocidad de carga de la página se puede optimizar convirtiéndola a base64.
La velocidad de solicitud de una imagen de 100 KB a través de http es de 1,1 s. El tamaño después de base64 es 120 KB, lo que aumentará el tamaño de js en 120 KB, por lo que el tiempo de carga aumentará en 1,2 s. Después de convertir a base64, la velocidad de carga de la página no se puede optimizar, pero la velocidad de carga sí. ralentizado en 0,1 s, lo que no es rentable.
Pensamiento:
Durante el proceso de desarrollo, además de la velocidad de carga, también debemos considerar el tema de la descarga paralela. Si están todos en un js y las imágenes no se descargan antes de descargar el js, es decir, después de base64, se puede considerar que los js y las imágenes se descargan en serie. Mediante la solicitud http, las imágenes se pueden descargar en paralelo usando js. Por lo tanto, en realidad necesitas una imagen más pequeña para que sea más rentable.