staba 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:

Reducirá la cantidad de solicitudes HTTP en la carga de la página, mejorando así el rendimiento 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ágenesos archivos @CSS se pueden almacenar en cachéos archivos @CSS pueden ser GZIPPED

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

Entonces, esta 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?

update - resultados de las pruebas

testing con imagen:http: //fragged.org/dev/map-shot.jp - 133.6Kb

test URL:http: //fragged.org/dev/base64.htm

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

GZIP que codifica el lado del servidor

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

Ahorro de datos enviados al navegador del cliente de: 74.3Kb

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

UPDATE: 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. Verhttp: //developer.chrome.com/devsummit/session y tenlo en cuenta - diapositiva real