[pastelsky]

Because the hex for green (#00ff00) needs more letters than using the named color.

[rawling]

Wouldn't that shorten to #0f0? But "green" is #008000, which doesn't shorten?

[zamadatix]

Hmm I wonder which approach is actually better overall when it comes to content-encoding like their own site uses (brotli compression) or client side parsing performance. It's all probably a bit off into the weeds over something like 0.05% performance though.

[yencabulator]

#080 is #008800, not #008000.

https://en.wikipedia.org/wiki/Web_colors#Shorthand_hexadecim...

[chronogram]

Ah thanks, I assumed ‘#0f0’ as well. I guess it is length based then.

[dymk]

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.

[robocat]

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).

[CognitiveLens]

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.

[marcosdumay]

> 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.

[pawelmurias]

I doubt that difference it takes to parse green vs a 0x00ff00 is at all significant. It only should happen once per page load.

[assemblylang]

>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.

[gampleman]

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.

[rattray]

I don't have intuition here, but perhaps transferring two bytes over a slow network takes longer than the string normalization and dictionary lookup?

[crehn]

> Because the hex for green (#00ff00) needs more letters than using the named color.

But "#0f0" is fewer letters than "green"?