You’re not allowed to make a performance argument like that unless you’re on some type of extremely limited embedded hardware or something. Especially when you are serving MBs of JavaScript. Gzip is good enough for over the wire size, and if parsing whitespace has got to be so close to free that it’s not going to be a problem. I say this from the top of my head, and it seems like the article back that up with data.
I don't have a stance on minifying CSS specifically, but extremely limited hardware is much more common than one might imagine. Billions of people exclusively access the internet through very under-powered and often old mobile phones with very limited bandwidth and monthly data quotas. I want my websites to work for them just as well as they do for people in wealthy countries.
But also, no amount of asset minification is going to make the gargantuan SPAs that took over the web run well on an underpowered device, so it is a wash either way, IMHO.
That depends a lot on the CSS. WebKit has had a JIT for CSS selectors for about ten years because they discovered that processing CSS selectors was the largest single consumer of time in their profiling traces for the top 100 web sites.
Ah, I definitely posted too quickly. I was thinking of css minification, ie, the topic of the article.
I can't imagine that skipping spaces and comments would matter compared to the rest of the rendering, compared to basically anything else you can do with your HTML and JS, and heavyweight CSS.
Yup, I'd imagine the tokenising phase of CSS shows up as a small fraction of 1% of even the CSS processing phase, let alone the entire page layout. Even rendering text in a variable-width true-type font uses vastly more compute than skipping whitespace.
The other thing to consider is the MTU size. It's likely that a small saving is basically eaten up entirely in the transfer size because it's the same number of packets. The delta described here might be one or two packets. With QUIC, each packet will start decoding as it arrives (with TLS, there's no direct correspondence between encrypted chunks and packets, so you may need N packets received before you can decrypt one, and some servers set this to a moderately large size, so the time to transmit those two extra packets may be measurable, but probably not significant). CSS parsing is done as soon as the data arrive, so the worst case is the last CSS rules are applied later than the others.
CSS is much better than JavaScript for this because JavaScript processing starts at the top level and the entry code is usually at the bottom after all of the other things have entered scope, so delaying the last line of a JavaScript file may mean delaying JavaScript execution, whereas delaying the last line of a CSS file just means some rules may end up being applied twice (higher CPU load but not such a latency spike).
As I said, I don't have an opinion on CSS specifically. I was responding to the statement that "[I'm] not allowed to make a performance argument like that unless you’re on some type of extremely limited embedded hardware".
But yes, my websites largely work without JavaScript.
Another class of devices are things like e-ink devices. You can be in the Western world and still be using an absolute toaster of a machine to render a webpage!
Like many things, it depends on context. Using more CSS might be preferable when dealing with limited hardware if it means less cost elsewhere.
I once worked in front-end performance for a big ecommerce site and a common task that I dealt with was refactoring naive React implementations of interactive components (e.g dropdowns, accordions, etc) so that they relied more on CSS than JavaScript. In most cases the additional CSS was superior to the removed JavaScript, not in terms of weight but in runtime performance as measured by the profiler and less jank in low-tier mobile devices.
extremely limited hardware is much more common than one might imagine. Billions of people exclusively access the internet through very under-powered and often old mobile phones with very limited bandwidth and monthly data quotas.
Where? Do we really have that data? I never got an answer that shows this is true today or was shown that this is a significant share of the market.
Average mobile speeds in many underdeveloped countries nowadays is north of 20 Mbps. Most underdeveloped countries have access to cheap and current mobile phones from China, none of which are old or underpowered. The combination of these two is more than enough to render any website.
Also "old" is a relative term that was more relevant 10 years ago. Today any 5 year old phone can render any reasonable website exactly the same as a flagship phone today.
Mobile networking and cellphone adoption has far outpaced all other kinds of infrastructure. The entire world is on a much more even ground than for everything else.
Of course, some are trying to buck that trend by delivering 50MB of JS and CSS on every request but for any website that is not insane minifying assets is not an issue at all anywhere.
We do, yes. Unfortunately in the developing world those statements do not hold true.
For example, I have family in Zimbabwe, a country where ~65% of people live below the world bank's poverty line, that is, they earn less than $3.64 a day. Modern devices are not available to these people, even with the advancements in cheap Chinese devices in recent years.
1GB of mobile data there cost $3.54 in 2024, which is the whole daily income for someone on the poverty line. The world bank currently calculates that 831 million people live in this level of poverty.
I care about minifying the text of this site more than the CSS. By the time the viewport is 707px wide, the article text is double the normal font size (± some font-size-adjust, depending on your font), so I have to zoom out to 70% or further for comfortable reading.
As regards the content: the testing methodology is very bad yielding certainly wrong results; my feeling is that a fixed version would show much smaller benefits to minification. (What was measured was also not particularly close to what had been suggested.) The synthetic stylesheet is wildly unrealistically simple, the minified version is completely broken (the semicolons are missing), latency effects are ignored even though they’re rather important in practice, the stylesheet is loaded via circuitous route rather than directly… there are enough really bad things that I’m not going to attempt to examine it in depth.
Minifying CSS has another use case: fair comparison of small stylesheets.
E.g. minifying the stylesheets from https://dohliam.github.io/dropin-minimal-css/ is a fairer comparison.
That way if a stylesheet looks "big", but has lots of comments, that is good, and shouldn't be considered "big".
OTOH if after minification one stylesheet is significantly larger than the other then you have to see whether it offers you any features you'd actually need to use.
And a small stylesheet will likely also have fewer rules. Even better if you can (automatically) drop CSS rules that your HTML doesn't use at all.
Sure that is not purely textual minification anymore, but it can help reduce and manage complexity.
If you're the kind of person that cares about the size of the (minified) stylesheet then it can help avoid making the stylesheets more complicated than necessary. And that can be good not just for performance, but also for future maintenance overhead.
I've seen it claimed that minified JS sometimes runs noticeably faster than unminified because (some) JS interpreters use the length of the source code of functions as part of their inlining heuristics.
I don’t know if this is still the case, but V8 used to do a first ‘parsing’ step that was just finding matching braces and then lazily parsed functions on demand and parsed them again for each JIT tier. Having the source code fit in cache, especially in L1, could improve performance.
For me, a large part of learning HTML and CSS back in the late ’90s and early 2000s was peeking at the source code of the webpages I saw, and I’ve never understood the desire to add an extra step to your pipeline that does nothing but prevent that.
These days anyone trying to take a site apart to see how it's made is going to be doing it with things like browser developer tools that reformat stuff for you anyway, so I'm not sure how much that argument still stands.
But I just wanted to point out one reason someone might want to do that - I've made a few HTML/CSS/Typescript games and I explicitly minify to strip comments out. I know all the code is there and I can't stop people going through that, but I can at least stop them reading my comments which contain notes, ideas and thoughts about the game that would give things away.
soulcutter | 5 days ago
You’re not allowed to make a performance argument like that unless you’re on some type of extremely limited embedded hardware or something. Especially when you are serving MBs of JavaScript. Gzip is good enough for over the wire size, and if parsing whitespace has got to be so close to free that it’s not going to be a problem. I say this from the top of my head, and it seems like the article back that up with data.
lpil | 5 days ago
I don't have a stance on minifying CSS specifically, but extremely limited hardware is much more common than one might imagine. Billions of people exclusively access the internet through very under-powered and often old mobile phones with very limited bandwidth and monthly data quotas. I want my websites to work for them just as well as they do for people in wealthy countries.
hjvt | 5 days ago
But also, no amount of asset minification is going to make the gargantuan SPAs that took over the web run well on an underpowered device, so it is a wash either way, IMHO.
lpil | 5 days ago
Totally. That's why I said I don't have an opinion on CSS minification, and why my sites largely render HTML on a server.
orib | 5 days ago
Do you serve your websites without Javascript? For most devices, CSS is negligible compared to nearly everything else websites do.
david_chisnall | 5 days ago
That depends a lot on the CSS. WebKit has had a JIT for CSS selectors for about ten years because they discovered that processing CSS selectors was the largest single consumer of time in their profiling traces for the top 100 web sites.
orib | 5 days ago
Ah, I definitely posted too quickly. I was thinking of css minification, ie, the topic of the article.
I can't imagine that skipping spaces and comments would matter compared to the rest of the rendering, compared to basically anything else you can do with your HTML and JS, and heavyweight CSS.
david_chisnall | 5 days ago
Yup, I'd imagine the tokenising phase of CSS shows up as a small fraction of 1% of even the CSS processing phase, let alone the entire page layout. Even rendering text in a variable-width true-type font uses vastly more compute than skipping whitespace.
The other thing to consider is the MTU size. It's likely that a small saving is basically eaten up entirely in the transfer size because it's the same number of packets. The delta described here might be one or two packets. With QUIC, each packet will start decoding as it arrives (with TLS, there's no direct correspondence between encrypted chunks and packets, so you may need N packets received before you can decrypt one, and some servers set this to a moderately large size, so the time to transmit those two extra packets may be measurable, but probably not significant). CSS parsing is done as soon as the data arrive, so the worst case is the last CSS rules are applied later than the others.
CSS is much better than JavaScript for this because JavaScript processing starts at the top level and the entry code is usually at the bottom after all of the other things have entered scope, so delaying the last line of a JavaScript file may mean delaying JavaScript execution, whereas delaying the last line of a CSS file just means some rules may end up being applied twice (higher CPU load but not such a latency spike).
lpil | 5 days ago
As I said, I don't have an opinion on CSS specifically. I was responding to the statement that "[I'm] not allowed to make a performance argument like that unless you’re on some type of extremely limited embedded hardware".
But yes, my websites largely work without JavaScript.
zmitchell | 5 days ago
Another class of devices are things like e-ink devices. You can be in the Western world and still be using an absolute toaster of a machine to render a webpage!
mayli | 5 days ago
Then maybe try to reduce the usage of CSS, avoid heavy libs and gzip.
ggpsv | 5 days ago
Like many things, it depends on context. Using more CSS might be preferable when dealing with limited hardware if it means less cost elsewhere.
I once worked in front-end performance for a big ecommerce site and a common task that I dealt with was refactoring naive React implementations of interactive components (e.g dropdowns, accordions, etc) so that they relied more on CSS than JavaScript. In most cases the additional CSS was superior to the removed JavaScript, not in terms of weight but in runtime performance as measured by the profiler and less jank in low-tier mobile devices.
kel | 5 days ago
Greater restrictions make for an even stronger justification for making quantified decisions through measurement instead of completely guessing
dlisboa | 5 days ago
Where? Do we really have that data? I never got an answer that shows this is true today or was shown that this is a significant share of the market.
Average mobile speeds in many underdeveloped countries nowadays is north of 20 Mbps. Most underdeveloped countries have access to cheap and current mobile phones from China, none of which are old or underpowered. The combination of these two is more than enough to render any website.
Also "old" is a relative term that was more relevant 10 years ago. Today any 5 year old phone can render any reasonable website exactly the same as a flagship phone today.
Mobile networking and cellphone adoption has far outpaced all other kinds of infrastructure. The entire world is on a much more even ground than for everything else.
Of course, some are trying to buck that trend by delivering 50MB of JS and CSS on every request but for any website that is not insane minifying assets is not an issue at all anywhere.
lpil | 5 days ago
We do, yes. Unfortunately in the developing world those statements do not hold true.
For example, I have family in Zimbabwe, a country where ~65% of people live below the world bank's poverty line, that is, they earn less than $3.64 a day. Modern devices are not available to these people, even with the advancements in cheap Chinese devices in recent years.
1GB of mobile data there cost $3.54 in 2024, which is the whole daily income for someone on the poverty line. The world bank currently calculates that 831 million people live in this level of poverty.
chrismorgan | 5 days ago
I care about minifying the text of this site more than the CSS. By the time the viewport is 707px wide, the article text is double the normal font size (± some font-size-adjust, depending on your font), so I have to zoom out to 70% or further for comfortable reading.
As regards the content: the testing methodology is very bad yielding certainly wrong results; my feeling is that a fixed version would show much smaller benefits to minification. (What was measured was also not particularly close to what had been suggested.) The synthetic stylesheet is wildly unrealistically simple, the minified version is completely broken (the semicolons are missing), latency effects are ignored even though they’re rather important in practice, the stylesheet is loaded via circuitous route rather than directly… there are enough really bad things that I’m not going to attempt to examine it in depth.
edwintorok | 5 days ago
Minifying CSS has another use case: fair comparison of small stylesheets. E.g. minifying the stylesheets from https://dohliam.github.io/dropin-minimal-css/ is a fairer comparison. That way if a stylesheet looks "big", but has lots of comments, that is good, and shouldn't be considered "big". OTOH if after minification one stylesheet is significantly larger than the other then you have to see whether it offers you any features you'd actually need to use.
And a small stylesheet will likely also have fewer rules. Even better if you can (automatically) drop CSS rules that your HTML doesn't use at all.
Sure that is not purely textual minification anymore, but it can help reduce and manage complexity. If you're the kind of person that cares about the size of the (minified) stylesheet then it can help avoid making the stylesheets more complicated than necessary. And that can be good not just for performance, but also for future maintenance overhead.
yawaramin | 5 days ago
I think the same argument can be made for JavaScript, actually!
0x2ba22e11 | 5 days ago
I've seen it claimed that minified JS sometimes runs noticeably faster than unminified because (some) JS interpreters use the length of the source code of functions as part of their inlining heuristics.
david_chisnall | 5 days ago
I don’t know if this is still the case, but V8 used to do a first ‘parsing’ step that was just finding matching braces and then lazily parsed functions on demand and parsed them again for each JIT tier. Having the source code fit in cache, especially in L1, could improve performance.
klingtnet | 5 days ago
Betteridge's law of headlines applies here, so the short answer is no.
jarofgreen | 5 days ago
These days anyone trying to take a site apart to see how it's made is going to be doing it with things like browser developer tools that reformat stuff for you anyway, so I'm not sure how much that argument still stands.
But I just wanted to point out one reason someone might want to do that - I've made a few HTML/CSS/Typescript games and I explicitly minify to strip comments out. I know all the code is there and I can't stop people going through that, but I can at least stop them reading my comments which contain notes, ideas and thoughts about the game that would give things away.