Hacker News new | ask | show | jobs
by dymk 1620 days ago
That's an... interesting optimization, and one that might make sense if you only care about byte size, but intuition (which might be wrong!) tells me that this will be more expensive (especially if it saves only one or two bytes).

I'd bet that browsers can more quickly parse a string like '0x00ff00' into its internal color representation than it can parse the string 'green'. It's probably faster to check for a '0x' prefix and convert hex-encoded ASCII to u8 values, than it is to normalize the string & do a lookup in a dictionary of 147 CSS3 color names, when taking into account the extra two bytes that need to be transferred.
7 comments
robocat 1620 days ago
More importantly, I would expect #00ff00 to compress better than green, because it would usually make the CSS file more predictably repetitive. Reducing network bytes is usually very important for speeding up loading (at least it is in the boondocks of the internet - out at the rim of the world).
link
chrismorgan 1620 days ago
A related thing that I realised a few days ago about compression algorithms:

  <!doctype html><meta charset=utf-8>
  <!DOCTYPE html><meta charset="utf-8">
Compress these with gzip, and the first is smaller than the second (56 and 58 bytes): lowercase doctype because you’re using very few uppercase letters in your document (on slightly larger samples it tends to save a byte or two), and omit the quotes as unnecessary. On larger documents there will be some places where you need quotes around attribute values, but it’s still worth omitting them when you can.

LZMA, similar: 60 and 63 bytes.

But then compress these with Brotli, and it’s the other way around by a larger margin, 29 and 19 bytes, because Brotli ships a dictionary primed on arbitrary web content. And so it becomes a popularity contest, and an inferior but vastly more popular technique compresses better.

In the case of #008000/green/#00ff00/#0f0/lime/#ffff00/#ff0/yellow, the dictionary doesn’t look to bee tainted, so traditional length and repetition wisdom still applies.

link
ry4nolson 1620 days ago
Someone else mentioned this already but "green" is not #00ff00. Tt's #008000.
link
CognitiveLens 1620 days ago
I don't get the sense that runtime CSS parsing is really much of a concern - it's more about build speed and asset size - since 'green' might be used hundreds of times in a large CSS bundle, the optimization might make sense even with an imperceptible speed cost in the browser.
link
marcosdumay 1620 days ago
> one that might make sense if you only care about byte size

A minimizer should care a lot abut size. I'm not sure what would be faster, but the difference must be minimal anyway, so it's safe to focus on your default concern.

link
pawelmurias 1620 days ago
I doubt that difference it takes to parse green vs a 0x00ff00 is at all significant. It only should happen once per page load.
link
assemblylang 1620 days ago
>That's an... interesting optimization, and one that might make sense if you only care about byte size, but intuition (which might be wrong!) tells me that this will be more expensive (especially if it saves only one or two bytes).

This is an interesting premise, do you know of any tools that optimize web pages for parsing and rendering speed as opposed to size? I wrote a tool once that bundles and archives webpages for offline viewing, and in those cases network throughput is not an issue since files are stored locally. It could be interesting to see what performance benefits I might be able to get from optimizing for parsing speed in this case, although I suspect the performance differences will be so negligible that it won't make much of a difference. Still would be an interesting experiment nonetheless.

link
gampleman 1620 days ago
Don’t know, but I wouldn’t be surprised if the browser first tried a dict lookup (which is super fast) and only then tried to actually parse hex the string.
link
rattray 1620 days ago
I don't have intuition here, but perhaps transferring two bytes over a slow network takes longer than the string normalization and dictionary lookup?
link