Hacker News Reader

Comment by CWIZO | Hacker News Reader

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.

Reply on news.ycombinator.com