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


131

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?


1
ya no mucha gente usa IE7 y, a pesar de todas las desventajas, hay una buena ventaja: ¡menos archivos de imagen para administrar! es decir, si necesita dibujar líneas especiales para un componente de árbol, entonces incrustar las pequeñas imágenes del codo en el propio CSS en combinación con repetir-x o repetir-y elimina la necesidad de asegurarse de que los archivos de imagen adicionales estén en el lugar correcto (con muy poco gastos generales para este caso de uso)
DaveAlger

Respuestas:


153

¿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.


2
@meo punto interesante. Espero que esto sea malo para el rendimiento de gzip, ya que las imágenes generalmente ya están comprimidas de manera muy óptima. Comprimirlos cuesta una cantidad horrible de espacio de CPU para ganancias porcentuales de un solo dígito. Intente descomprimir un archivo JPG y verá lo que quiere decir. Lo editaré en la respuesta
Pekka

1
Sé que comprimir imágenes comprimidas no es el camino a seguir. Pero estaba pensando que quizás sea más efectivo en la base 64. Especialmente cuando tienes más de una imagen en la fuente.
Meo

2
@meo no, no será más efectivo en base64 bajo ninguna circunstancia, porque los patrones subyacentes seguirán siendo los datos de imagen comprimidos que simplemente se expresan en notación base64.
Pekka

1
@meo ah, ya veo. Eso no funcionará en IE en absoluto, y tiene el mismo problema de capacidad de almacenamiento en caché: guarda una solicitud, pero cada solicitud de página crece en tamaño. Por lo general, es mucho mejor compactar todo en un CSS y un archivo JS
Pekka

55
No NO inflar la página HTML cuando está incrustando las imágenes en un archivo CSS como la cuestión indica.
Daniel Beardsley

38

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.


44
Esto debería ser votado para obtener más atención. otras respuestas son un poco obsoletas: hablan de IE6 mientras que IE8 está un poco obsoleto en estos días ... (y gracias por eso)
Hertzel Guinness

11

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:

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.

3
CSS se vuelven a descargar en cada solicitud? Esa es una nueva! Además, si alguna vez archivó un archivo en su vida, ¡se habría dado cuenta de que la tasa de compresión no es del 2-3%! Si no me equivoco, primero vi esta técnica implementada en yahoo.com. ... claramente no es una buena práctica!
StefanNch

@StefanNch eso no es lo que dice. En el extracto, "que contiene el documento" se refiere al archivo css.
Christophe

9

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


3

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.


Ya tengo sprites, me preguntaba si puedo optimizarlo aún más con ese método.
Meo

2

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?


44
causa número de solicitudes es uno de los mayores éxitos de rendimiento si le importa perf es lo primero que debe tratar y abordar. vea la toma de yahoo developer.yahoo.com/performance/rules.html "Reducir la cantidad de componentes a su vez reduce la cantidad de solicitudes HTTP requeridas para representar la página. Esta es la clave para páginas más rápidas".
MemeDeveloper

0

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/

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.