¿Incrustar datos de imágenes de fondo en CSS como Base64 es una buena o mala práctica?

Estaba mirando la fuente de un script de usuario de greasemonkey y noté lo siguiente en su CSS:

.even { background: #fff url(data:image/gif;base64,R0lGODlhBgASALMAAOfn5+rq6uvr6+zs7O7u7vHx8fPz8/b29vj4+P39/f///wAAAAAAAAAAAAAAAAAAACwAAAAABgASAAAIMAAVCBxIsKDBgwgTDkzAsKGAhxARSJx4oKJFAxgzFtjIkYDHjwNCigxAsiSAkygDAgA7) repeat-x bottom}

Puedo apreciar que un script de greasemonkey querría agrupar todo lo que pueda dentro de la fuente en lugar de alojarlo en un servidor, eso es bastante obvio. Pero como no había visto esta técnica anteriormente, consideré su uso y parece atractivo por varias razones:

1. Reducirá la cantidad de solicitudes HTTP en la carga de la página, mejorando así el rendimiento
2. Si no hay CDN, reducirá la cantidad de tráfico generado a través de las cookies que se envían junto con las imágenes
3. Los archivos CSS se pueden almacenar en caché
4. Los archivos CSS pueden ser GZIPPED

Teniendo en cuenta que IE6 (por ejemplo) tiene problemas con el caché para imágenes de fondo, parece que no es la peor idea ...

Entonces, ¿es una buena o mala práctica, por qué NO la usarías y qué herramientas usarías para codificar las imágenes en base64?

actualización: resultados de las pruebas

• prueba con imagen: http://fragged.org/dev/map-shot.jpg - 133.6Kb

• URL de prueba: http://fragged.org/dev/base64.html

• archivo CSS dedicado: http://fragged.org/dev/base64.css - 178.1Kb

• Lado del servidor de codificación GZIP

• tamaño resultante enviado al cliente (prueba de componentes YSLOW): 59.3Kb

• Guardado de datos enviados al navegador del cliente de: 74.3Kb

Agradable, pero supongo que será un poco menos útil para imágenes más pequeñas.

ACTUALIZACIÓN: Bryan McQuade, un ingeniero de software de Google, que trabaja en PageSpeed, expresó en ChromeDevSummit 2013 que los datos: uris en CSS se considera un antipatrón de bloqueo de renderizado para entregar CSS crítico / mínimo durante su charla #perfmatters: Instant mobile web apps. Consulta http://developer.chrome.com/devsummit/sessions y tenlo en cuenta: diapositiva real

No es una buena idea cuando desea que sus imágenes e información de estilo se almacenen en caché por separado. Además, si codifica una imagen grande o una cantidad significativa de imágenes en su archivo CSS, el navegador tardará más en descargar el archivo que sale de su sitio sin ninguna información de estilo hasta que se complete la descarga. Para imágenes pequeñas que no tiene la intención de cambiar a menudo, si alguna vez es una buena solución.

en cuanto a generar la codificación base64:

• http://b64.io/
• http://www.motobit.com/util/base64-decoder-encoder.asp (subir)
• http://www.greywyvern.com/code/php/binary2base64 (del enlace con pequeños tutoriales debajo)

Esta respuesta está desactualizada y no debe usarse.

1) La latencia promedio es mucho más rápida en dispositivos móviles en 2017. https://opensignal.com/reports/2016/02/usa/state-of-the-mobile-network

2) multiplexes HTTP2 https://http2.github.io/faq/#why-is-http2-multiplexed

Los "URI de datos" definitivamente deberían considerarse para los sitios móviles. El acceso HTTP a través de redes celulares viene con una mayor latencia por solicitud / respuesta. Por lo tanto, hay algunos casos de uso en los que bloquear sus imágenes como datos en plantillas CSS o HTML podría ser beneficioso para las aplicaciones web móviles. Debería medir el uso caso por caso: no estoy abogando por que los URI de datos se usen en todas partes en una aplicación web móvil.

Tenga en cuenta que los navegadores móviles tienen limitaciones en el tamaño total de los archivos que se pueden almacenar en caché. Los límites para iOS 3.2 eran bastante bajos (25K por archivo), pero se están volviendo más grandes (100K) para las versiones más nuevas de Mobile Safari. Por lo tanto, asegúrese de controlar el tamaño total de su archivo al incluir los URI de datos.

http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/

Si hace referencia a esa imagen solo una vez, no veo ningún problema para incrustarla en su archivo CSS. Pero una vez que use más de una imagen o necesite hacer referencia a ella varias veces en su CSS, puede considerar usar un solo mapa de imagen en su lugar y luego puede recortar sus imágenes individuales (consulte CSS Sprites ).

Una de las cosas que sugeriría es tener dos hojas de estilo separadas: una con sus definiciones de estilo regulares y otra que contenga sus imágenes en codificación base64.

Debe incluir la hoja de estilo base antes de la hoja de estilo de imagen, por supuesto.

De esta forma, se asegurará de que su hoja de estilo regular se descargue y aplique lo antes posible al documento, pero al mismo tiempo se beneficiará de la reducción de las solicitudes http y otros beneficios que le brindan los datos uris.

Base64 agrega aproximadamente un 10% al tamaño de la imagen después de GZipped, pero eso supera los beneficios cuando se trata de dispositivos móviles. Dado que existe una tendencia general con un diseño web receptivo, es muy recomendable.

W3C también recomienda este enfoque para dispositivos móviles y, si utiliza la canalización de activos en rieles, esta es una característica predeterminada al comprimir su CSS

http://www.w3.org/TR/mwabp/#bp-conserve-css-images

No estoy de acuerdo con la recomendación de crear archivos CSS separados para imágenes no editoriales.

Suponiendo que las imágenes son para fines de interfaz de usuario, es el estilo de la capa de presentación, y como se mencionó anteriormente, si está haciendo una interfaz de usuario móvil, definitivamente es una buena idea mantener todo el estilo en un solo archivo para que se pueda almacenar en caché una vez.

En mi caso, me permite aplicar una hoja de estilo CSS sin preocuparme por copiar imágenes asociadas, ya que ya están incrustadas en su interior.

Traté de crear un concepto en línea de la herramienta de análisis CSS / HTML:

http://www.motobit.com/util/base64/css-images-to-base64.asp

Puede:

• Descargue y analice archivos HTML / CSS, extraiga elementos href / src / url
• Detectar compresión (gzip) y datos de tamaño en la URL
• Compare el tamaño de datos original, el tamaño de datos base64 y el tamaño de datos base64 comprimido.
• Convierta la URL (imagen, fuente, css, ...) en un esquema de URI de datos base64.
• Cuente el número de solicitudes que pueden ser ahorradas por los URI de datos

Comentarios / sugerencias son bienvenidos.

Antonin

Puedes codificarlo en PHP :)

<img src="data:image/gif;base64,<?php echo base64_encode(file_get_contents("feed-icon.gif")); ?>">

Or display in our dynamic CSS.php file:

background: url("data:image/gif;base64,<?php echo base64_encode(file_get_contents("feed-icon.gif")); ?>");

1 That’s sort of a “quick-n-dirty” technique but it works. Here is another encoding method using fopen() instead of file_get_contents():

<?php // convert image to dataURL
$img_source = "feed-icon.gif"; // image path/name
$img_binary = fread(fopen($img_source, "r"), filesize($img_source));
$img_string = base64_encode($img_binary);
?>

Fuente

Trayendo un poco para los usuarios de Sublime Text 2, hay un complemento que proporciona el código base64 que cargamos las imágenes en el ST.

Llamado Image2base64: https://github.com/tm-minty/sublime-text-2-image2base64

PD: nunca guarde este archivo generado por el complemento porque sobrescribiría el archivo y lo destruiría.

Gracias por la información aquí. Considero que esta incrustación es útil y particularmente para dispositivos móviles, especialmente con el archivo css de las imágenes incrustadas en caché.

Para ayudar a hacer la vida más fácil, ya que mi (s) editor (es) de archivos no manejan esto de manera nativa, hice un par de scripts simples para el trabajo de edición de computadora portátil / escritorio, compartir aquí en caso de que sean de utilidad para alguien más. Me he quedado con php ya que está manejando estas cosas directamente y muy bien.

En Windows 8.1 diga ---

C:\Users\`your user name`\AppData\Roaming\Microsoft\Windows\SendTo

... allí, como administrador, puede establecer un acceso directo a un archivo por lotes en su ruta. Ese archivo por lotes llamará a un script php (cli).

Luego puede hacer clic con el botón derecho en una imagen en el explorador de archivos y Enviar al archivo por lotes.

Acepte la solicitud del Admiinstartor y espere a que se cierren las ventanas negras del shell de comandos.

Luego, simplemente pegue el resultado del portapapeles en su editor de texto ...

<img src="|">

o

 `background-image : url("|")` 

Los siguientes deben ser adaptables para otros sistemas operativos.

Archivo por lotes...

rem @echo 0ff
rem Puts 64 encoded version of a file on clipboard
php c:\utils\php\make64Encode.php %1

Y con php.exe en su camino, eso llama un script php (cli) ...

<?php 

function putClipboard($text){
 // Windows 8.1 workaround ...

  file_put_contents("output.txt", $text);

  exec("  clip < output.txt");

}


// somewhat based on http://perishablepress.com/php-encode-decode-data-urls/
// convert image to dataURL

$img_source = $argv[1]; // image path/name
$img_binary = fread(fopen($img_source, "r"), filesize($img_source));
$img_string = base64_encode($img_binary);

$finfo = finfo_open(FILEINFO_MIME_TYPE); 
$dataType = finfo_file($finfo, $img_source); 


$build = "data:" . $dataType . ";base64," . $img_string; 

putClipboard(trim($build));

?>

Por lo que he investigado,

Uso: 1. Cuando usa un sprite svg. 2. Cuando sus imágenes son de menor tamaño (máximo 200mb).

No utilice: 1. Cuando son imágenes más grandes. 2. Iconos como svg's. Como ya están bien y gzip después de la compresión.