Is embedding background image data into CSS as Base64 good or bad practice?

by

I was looking at the source of a greasemonkey userscript and noticed the following in their css:

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

I can appreciate that a greasemonkey script would want to bundle anything it can within the source as opposed to host it on a server, that’s obvious enough. But since I had not seen this technique previously, I considered its use and it seems appealing for a number of reasons:

  1. It will reduce the amount of HTTP requests on page load, thus enhancing performance
  2. If no CDN, then it will reduce the amount of traffic generated through cookies being sent alongside of images
  3. CSS files can be cached
  4. CSS files can be GZIPPED

Considering that IE6 (for instance) has problems with cache for background images, this seems like it’s not the worst idea…

So, is this a good or bad practice, why WOULDN’T you use it and what tools would you use to base64 encode the images?

update – results of testing

  • testing with image: http://fragged.org/dev/map-shot.jpg – 133.6Kb

  • test URL: http://fragged.org/dev/base64.html

  • dedicated CSS file:
    http://fragged.org/dev/base64.css –
    178.1Kb

  • GZIP encoding server side

  • resulting size sent to client (YSLOW
    components test): 59.3Kb

  • Saving of data sent to client browser of: 74.3Kb

Nice, but it will be slightly less useful for smaller images, I guess.

UPDATE: Bryan McQuade, a software engineer at Google, working on PageSpeed, expressed at ChromeDevSummit 2013 that data:uris in CSS is considered a render-blocking anti-pattern for delivering critical/minimal CSS during his talk #perfmatters: Instant mobile web apps. See http://developer.chrome.com/devsummit/sessions and keep that in mind – actual slide

12 s
12

Leave a Comment