The huffman coding in gzip reduces this down to almost nothing, as the base64-encoded data only has 6 bits of entropy per byte, which negates the 1/3 increase in bytes.
In practice the difference is less than the HTTP protocol overhead for an extra request.
There are other reasons why you might not want to use data URLs, but this isn't a valid one.
For example, you can't re-use the same image in other CSS files without duplicating the image's download cost as it's the surrounding CSS file that's cached, not the image itself. At the same time, you download all the data URL images with the CSS, regardless of whether the user ever gets to see them on the current page. Fine in some cases, not so much in others.
> For example, you can't re-use the same image in other CSS files without duplicating the image's download cost as it's the surrounding CSS file that's cached, not the image itself.
On the other hand, you could create css classes like
well, yes and no; having them put away into a separate css file would be an extra http request, but it's not fair to say "therefore you might as well use sprites", because the chances are you're going to have a global stylesheet that you can tack the images onto the end of; no extra HTTP requests.
Sorry, poor choice of words. It brings the size down to almost the original and is probably irrelevant. Off course this depends on the site you have. It is possible that in some cases you will get substantially bigger files.
In my experience it's typically less than 100 bytes. You'll struggle to squeeze the HTTP overhead below that.
Anecdotal evidence: I just base64+gzipped a JPEG with 13668 bytes. Result: 13713 bytes, delta: 45 (0.3%).
Command used:
base64 -w 0 infile | gzip -9 -n > outfile
For HTTP you can even use raw deflate, which does away with some of the gzip file format overhead. IIRC this saves you another 18 bytes for the header (10 bytes) and footer (8 bytes).
Tangent: the reason I'm such a gzip nerd is that I used it to implement compression for level assets in Battalion Wars 2 for the Wii. I didn't want to make up yet another format, and gzip was ideal save for the fact that the size of the raw data is stored at the end of the file. We needed the info to allocate the necessary memory, but seeking to the end would have caused some latency from the DVD drive mechanism. The solution was to add a proprietary header which is ignored by the gzip code and the rest of the toolchain.
