¿Debo incrustar imágenes como data / base64 en CSS o HTML

Para reducir el número de solicitudes en el servidor, he incrustado algunas imágenes (PNG y SVG) como BASE64 directamente en el CSS. (Está automatizado en el proceso de construcción)

Me gusta esto:

background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAFWHRTb2Z0d2FyZQBBZG etc...);

¿Es esta una buena practica? ¿Hay algunas razones para evitar esto? ¿Hay algún navegador importante que no tenga soporte de URL de datos?

Pregunta adicional: ¿Tiene sentido hacer esto también para CSS y JS?

¿Es esta una buena practica? ¿Hay algunas razones para evitar esto?

Es una buena práctica generalmente solo para imágenes CSS muy pequeñas que se usarán juntas (como sprites CSS) cuando la compatibilidad con IE no importa, y guardar la solicitud es más importante que la capacidad de almacenamiento en caché.

Tiene una serie de desventajas notables:

• No funciona en absoluto en IE6 y 7.

• Funciona para recursos de hasta 32k de tamaño en IE8 . Este es el límite que se aplica después de la codificación base64. En otras palabras, no más de 32768 caracteres.

• Guarda una solicitud, ¡pero en cambio hincha la página HTML! Y hace que las imágenes no se puedan almacenar en caché. Se cargan cada vez que se carga la página que contiene o la hoja de estilo.

• La codificación Base64 aumenta el tamaño de las imágenes en un 33%.

• Si se sirve en un recurso comprimido, ¡las data:imágenes seguramente serán una carga terrible para los recursos del servidor! Tradicionalmente, las imágenes requieren mucha CPU para comprimir, con muy poca reducción de tamaño.

Las respuestas comunes aquí parecen sugerir que esto no es necesario, por una serie de razones legítimas. Sin embargo, todo esto parece descuidar el comportamiento de las aplicaciones modernas y el proceso de compilación.

No es imposible (y en realidad es bastante fácil) diseñar un proceso simple que recorra las imágenes de una carpeta y genere un solo CSS con todas las imágenes de esta carpeta.

Este css se almacenará en caché por completo y reducirá drásticamente los viajes de ida y vuelta al servidor, lo cual es, como sugiere correctamente @MemeDeveloper, uno de los mayores éxitos de rendimiento.

Claro, es un hack. sin duda. lo mismo que los sprites son un hack. En el mundo perfecto, esto no será necesario, hasta entonces, es una práctica posible si lo que necesita arreglar es:

1. Página con múltiples imágenes que no son fácilmente "spritable".
2. El viaje de ida y vuelta a los servidores es un cuello de botella real (piense en dispositivos móviles).
3. la velocidad (al nivel de milisegundos) es realmente tan importante para su caso de uso.
4. No le importa (como debería, si desea que la web avance) sobre IE5 e IE6.

mi vista.

No es una buena práctica. Algunos navegadores no admiten URI de datos (por ejemplo, IE 6 y 7) o el soporte es limitado (por ejemplo, 32 KB para IE8).

Consulte también este artículo de Wikipedia para obtener detalles completos sobre las desventajas del URI de datos:

• Esquema de URI de datos

Desventajas

• Los URI de datos no se almacenan en caché por separado de los documentos que los contienen (por ejemplo, archivos CSS o HTML), por lo que los datos se descargan cada vez que se vuelven a descargar los documentos que los contienen.
• El contenido se debe volver a codificar y volver a incrustar cada vez que se realiza un cambio.
• Internet Explorer hasta la versión 7 (aproximadamente el 15% del mercado a partir de enero de 2011) carece de soporte.
• Internet Explorer 8 limita los URI de datos a una longitud máxima de 32 KB.
• Los datos se incluyen como una secuencia simple, y muchos entornos de procesamiento (como los navegadores web) pueden no ser compatibles con el uso de contenedores (como multipart/alternativeo message/rfc822) para proporcionar una mayor complejidad, como metadatos, compresión de datos o negociación de contenido.
• Los URI de datos codificados en Base64 son 1/3 más grandes que su equivalente binario. (Sin embargo, esta sobrecarga se reduce a 2-3% si el servidor HTTP comprime la respuesta usando gzip)
• Los URI de datos dificultan que el software de seguridad filtre el contenido.

Estuve usando data-uri's durante aproximadamente un mes, y simplemente dejé de usarlos porque hicieron que mis hojas de estilo fueran absolutamente enormes.

Data-uri's funciona en IE6 / 7 (solo necesita entregar un archivo mhtml a esos navegadores)

El único beneficio que obtuve al usar data-uri fue que mis imágenes de fondo se representaron tan pronto como se descargó la hoja de estilo, en lugar de la carga gradual que vemos de otra manera

Es bueno que tengamos esta técnica disponible, pero no la usaré demasiado en el futuro. Sin embargo, recomiendo probarlo, solo para que lo sepas por ti mismo

Me inclinaba más por usar CSS Sprites para combinar las imágenes y guardar en las solicitudes. Nunca he probado la técnica de base64 pero aparentemente no funciona en IE6 e IE7. También significa que si alguna imagen cambia, debe volver a entregar toda la pérdida, a menos que tenga varios archivos CSS, por supuesto.

No tengo idea de las mejores prácticas generales, pero por mi parte no me gustaría ver ese tipo de cosas si pudiera evitarlo. :)

Los navegadores web y los servidores tienen un montón de cosas de almacenamiento en caché integradas, por lo que habría pensado que su mejor opción era hacer que su servidor le dijera al cliente que guarde en caché los archivos de imagen. A menos que tenga un montón de imágenes realmente pequeñas en una página, no habría pensado que la sobrecarga de múltiples solicitudes fuera tan importante. Los navegadores generalmente usarán la misma conexión para solicitar muchos archivos, por lo que no se establecerán nuevas conexiones de red, a menos que el volumen de tráfico a través de los encabezados HTTP sea significativo en comparación con el tamaño de los archivos de imagen, no me preocuparía demasiado por las solicitudes múltiples. .

¿Hay razones por las que cree que hay demasiadas solicitudes dirigidas al servidor en este momento?

Lo sugeriría para imágenes pequeñas que se usan con mucha frecuencia, por ejemplo, iconos comunes de una aplicación web.

• Diminuto, porque la codificación Base64 aumenta el tamaño
• A menudo se usa, porque esto justifica el mayor tiempo de carga inicial

Por supuesto, deben tenerse en cuenta los problemas de soporte con navegadores antiguos. También podría ser una buena idea usar la capacidad de un marco para alinear automáticamente las imágenes de una URL de datos como ClientBundle de GWT o al menos usar clases CSS en lugar de agregarlo directamente al estilo del elemento.

Aquí se recopila más información: http://davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/