Eu estava olhando para a fonte de um userscript greasemonkey e notei o seguinte em seu css:

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

Eu posso entender que um script greasemonkey gostaria de agrupar qualquer coisa dentro da fonte, em vez de hospedá-lo em um servidor, isso é bastante óbvio. Mas como eu não tinha visto essa técnica anteriormente, considerei seu uso e parece atraente por vários motivos:

Isso reduzirá a quantidade de solicitações HTTP no carregamento da página, aprimorando o desempenhoSe não houver CDN, reduzirá a quantidade de tráfego gerada pelos cookies enviados ao lado das imagensArquivos CSS podem ser armazenados em cacheArquivos CSS podem ser GZIPPED

Considerando que o IE6 (por exemplo) tem problemas com cache para imagens de fundo, isso parece não ser a pior idéia ...

Então, isso é uma prática boa ou ruim, por que você não usaria e quais ferramentas você usaria para codificar as imagens?

atualização - resultados do teste

testando com imagem:http://fragged.org/dev/map-shot.jpg - 133,6 Kb

URL de teste:http://fragged.org/dev/base64.html

arquivo CSS dedicado:http://fragged.org/dev/base64.css - 178,1 Kb

Lado do servidor de codificação GZIP

tamanho resultante enviado ao cliente (teste de componentes YSLOW):59,3 Kb

Salvamento de dados enviados para o navegador do cliente de:74,3 Kb

Bom, mas será um pouco menos útil para imagens menores, eu acho.

ATUALIZAÇÃO: Bryan McQuade, engenheiro de software do Google, trabalhando no PageSpeed, expressou no ChromeDevSummit 2013 que os dados: uris em CSS é considerado um anti-padrão de bloqueio de renderização para entregar CSS crítico / mínimo durante seu discurso#perfmatters: Instant mobile web apps. Vejohttp://developer.chrome.com/devsummit/sessions e mantenha isso em mente -slide real