Hacker News Reader

Comment by pmjordan | Hacker News Reader

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.

View on HN

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