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