views:

125

answers:

4

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?

+1  A: 

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.

scunliffe
+2  A: 

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.

Keith
+1  A: 

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

A: 

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
Kevin Hakanson