RSS Feed

Avoid Data URIs



One of the recent hot trends in web design is to mimic technologies without really using them. Mostly as POCs and sometimes seriously, talented Front End Developers created Javascript-less animations, image-less symbols and effects and even image-less images - Or in our case, without external files.

Data URI

The idea of Data URIs is to embed all image data in the document, where you normally put a URL referencing the image file. This data is usually represented as a base64 encoded string.

Embedding image data inline saves HTTP requests, cancels the need for taking sprite coordinates and might feel more instant as images load right with all other content. This idea gains traction, and related tools are launched rapidly.

Doesn't sound too bad, does it?

To top it off, the W3C Mobile Work Group has just released the Mobile Web Application Best Practices as an official recommendation, and section 3.4.7 is titled "Include Background Images Inline in CSS Style Sheets". Quoting it here for your convenience: What it means

Visual effects (e.g. background images and gradients) are often used to improve the look and feel of an application. These can be included in CSS as base64 encoded strings in order to avoid an additional HTTP request

Note that base64 encoding adds around 10% to the image size after gzip compression and this additional cost should be weighed against the benefits of fewer requests. How to do it

Background images can be encoded using the data URI scheme: url('data:image/png;base64, [data])

[ CSS ] Requires: RFC2397 [RFC2397] data uri support.

Why you should avoid such a marvelous idea

  • IE 6 and 7 doesn't support the Data URI scheme at all. We're talking images here, not rounded corners - You have to support it, which means you should use the Microsoft proprietry MHTML (presented with IE5.5 in '99), but then code weight is more than doubled.
  • Even without MHTML, Data-URI images weigh around %36 more than PNG. GZipping the text makes it about %6 more, but it's still something.
  • There's an extra step to build a webpage, and if you want it to be remotely maintainable you'll add comments referring to the original image, which should be stored somewhere.
  • Images always download, unlike referenced images in CSS declarations which doesn't apply on a given page. Go ahead, try it.
  • Images aren't cached separately, so embedding in HTML doesn't cache at all, and embedding in CSS means any change you do to the CSS invalidates all embedded images' cache.
  • You might be thinking now "That's not a problem, I'll combine groups of related image in dedicated external stylesheet, i.e. header-sprite.css". Congrats, you've just reached image sprites with 10 more limitations.
  • CSS blocks download, unlike images, so you don't want to bloat it too much.
  • IE8 can't handle Data URIs over 32KB, so that rules out content images
  • Maintaining sprites is still more natural and easy - Who misses image slicing?
  • These URIs are damn ugly. Even in Firebug, even in wide screens, they are human-unreadable, create terribly long lines and just makes their hosting files dirty.

To conclude, this technology is available in most of today's browsers and that's dandy, but don't get overboard. The pros are few and are outweighted by the cons in almost any case.

Related Content

What do you think?