Using an image file vs data URI in the CSS

Question

I'm trying to decide the best way to include an image that is required for a script I've written.

I discovered this site and it made me think about trying this method to include the image as a data URI (defined by RFC 2397) since it was so small - it's a 1x1 pixel 50% opacity png file (used for a background) - it ends up at 2,792 bytes as an image versus 3,746 bytes as text in the CSS.

So would this be considered good practice, or would it just clutter up the CSS unnecessarily?

Overstate

Answer 1

I don't think you will gain much... and if it is a file image, the browser can cache it. I wouldn't bother doing it with CSS unless you have a real need for it.

Moretta

Answer 2

There is a good reason for using a Data URI, rather than the image.

The Data URI is base 64 encoded, which means that it's about 25% bigger than the image. However your CSS file can be cached, so the small size increase probably isn't a big problem.

If you have a lot of images there's an overhead for looking up each one, both in terms of name resolution and getting the image as another resource.

All this means that if images are small, and the overall CSS file is still small, and the CSS is shared between pages that are hit often then you stand to gain performance if you switch to data URIs.

The downside is that they only work in FX, Chrome, etc. The partially work in IE8, but only for small images. They don't work in IE7 or below at all.

Mccusker

You say that the css file will be cached but there is a downside if you really think about it. When you bundle the css file, you get the new css and the old css is invalidated. You could have saved those extra bytes by caching the image separately. – Outrigger

@JaspreetSingh it very much depends on how you bundle the CSS - visitors still shouldn't be getting the CSS again on each visit, and the cache or service worker should be holding on to between visits (if the version hasn't changed). It's really a question of bandwidth vs ping - the CSS file is bigger but you save yourself a round trip for the image. Most of the time that isn't enough of an overhead to be worth the extra bytes, but not always. – Mccusker

Answer 3

I think it's negligible right now.. (one image that's small?)

However, there are some other things to consider:

1. Will there be the possiblity of more images in the future?
2. Do you gZip your css files?

Reason being..
For every image loaded into css is one less call to the server, which takes time. We all know that from sprites. Even a larger sized sprite, than all the images combined, is preferrable. That means that every image that's added, is one less potential slowdown, if you use data: URI.

and for the second question.. data: URI is VERY gZip friendly. I mean VERY. We have some legacy css files that are huge. 109 kb huge.. and when we data:URI the image, that inflates into a whopping 246 kb! After gZipping, we are down to 126 kb.

Not to mention.. sprites are not fun to maintain, but there is far less reason to sprite if you are using data: URI.

Hope that helps.

PS. a link regarding data:URI. http://www.nczonline.net/blog/2010/07/06/data-uris-make-css-sprites-obsolete/#comment-5800

PS PS check the bottom of that page, to find out more Nicolas has to say about data:URI

Calva

Answer 4

Using Data URIs refers to Data URIs make CSS sprites obsolete and extends the use of the CSSEmbed tool by creating an Ant build step. CSSEmbed "also supports an MHTML mode to make IE6 and IE7 compatible stylesheets that use internal images similar to data URIs."

Also, when comparing image file bytes to base64 encoded bytes, don't forget that each http image request/response has the bytes overhead of the http headers. This example going against Yahoo consumes about 900 bytes (I did modify the proxy name to example.com). Furthermore, the yimg.com domain is optimized to not have any cookies and saving those potential bytes.

GET http://l.yimg.com/a/i/ww/met/yahoo_logo_us_061509.png HTTP/1.1
Accept: */*
Referer: http://www.yahoo.com/
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB6.5; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET4.0C; .NET4.0E)
Accept-Encoding: gzip, deflate
Host: l.yimg.com
Proxy-Connection: Keep-Alive

HTTP/1.0 200 OK
Date: Sat, 31 Jul 2010 22:27:25 GMT
Cache-Control: max-age=315360000
Expires: Tue, 28 Jul 2020 22:27:25 GMT
Last-Modified: Wed, 16 Jun 2010 18:06:49 GMT
Accept-Ranges: bytes
Content-Length: 1750
Content-Type: image/png
Age: 321472
Server: YTS/1.17.23.1
X-Cache: MISS from a-proxy-server.example.com
Via: 1.0 a-proxy-server.example.com:80 (squid/2.6.STABLE22)
Proxy-Connection: keep-alive

Recalesce

Answer 5

When To Use Data URIs

When used instead of an image sprite, data URIs save a single HTTP request, and every little bit counts. However they are even more useful for images that are difficult to include in sprite sheets, for instance custom list bullets that need a varying amount of whitespace.

Although data URIs are an excellent way to reduce HTTP requests, it doesn’t make sense to use them in every situation. Since they embed the raw file data directly in the stylesheet, data URIs can lead to stylesheet bloat if they are used heavy-handedly.

Below are some useful links.

http://jonraasch.com/blog/css-data-uris-in-all-browsers

http://www.phpied.com/mhtml-when-you-need-data-uris-in-ie7-and-under/

Heriberto