Comment by pilif | Hacker News Reader

Comment by pilif | Hacker News Reader

mmh... there are two kinds of overhead associated with using data URLs.

One is that encoding arbitrary binary data using base64 will increase the size of the data by around one third, so you will transmit more data.

Of course, if you do the caching headers right, this applies only to the first connection.

The other overhead you have to pay for every time: The data has to be base64 decoded before it can be used. Depending on the amount and size of images and depending on the type of implementation in the browser, this can require a significant amount of resources.

edit: In addition I wonder whether browsers cache the base64 decoded output between page loads. If you are really unlucky, the decoding might be done on every page load. Also, I'm not sure how browsers would handle identical data-content in multiple CSS rules: Do they keep multiple copies of the same image in memory? Or do they detect identical data and keep only one image around?

I would do some tests before blindly applying this.

The other overhead you have to pay for every time: The data has to be base64 decoded before it can be used.

Compared to decompressing the PNG or JPEG data, decoding base64 is essentially free. It will therefore also not matter much at what stage it's cached.

Maybe. The JPEG decompression has been mercilessly optimized for decades.

The oddball base64 URI decode might have been done by the team's crappy coder that no one trusts, but you can write decent test cases for base64 decoding, so you can burn his hours for a few weeks without him doing any lasting harm to the code base.

Using gzip you negate the increase in size (article (or a linked article) mentions that).

not completely. size(gzip(base64(compressed_image))) is highly likely bigger than just size(compressed_image)

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.

Anybody up for doing some experiments?

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.

I just tested some PNGs that I am currently using in a sprite. These are transparent arrows used for slideshow control. Four images make the sprite:

Individual image sizes: 1811, 1809, 1774, 1817 bytes

Combined in a sprite: 5970 bytes

Individual images after base64: 2448, 2444, 2400, 2456 bytes

Individual images base64+gzip: 1890, 1887, 1858, 1901 bytes

Concatenate base64 files to simulate embedding in a CSS file: 9748 bytes

Concatenated file + gzip: 7073 bytes

Thanks. Doesn't sound too bad. Or does it?

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.

There are other reasons why you might not want to use data URLs, but this isn't a valid one.

Which?

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

  .someImage { background: url(...) no-repeat; }

and stick them in a sitewide stylesheet.

Though then you may as well use a sprite atlas, as you're introducing a new HTTP request anyway.

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.

Ok, thanks for thinking for me. :)

On your further answers, data URLs are far better than sprites in maintainability, not(no rewriting of the map etc)?

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.

Thats also true for sprites, i think.

Firefox keeps a copy of every image on screen decompressed in memory anyway, that's one of the downsides to using large sprites, they can take up a large amount of RAM. I doubt non-sprited base64 images compare in size issues.

See the discussion on http://blog.mozilla.com/webdev/2009/03/27/css-spriting-tips/

Reply on news.ycombinator.com