Complete side note: I’m on public wifi right now and the domain used to host the images in this article is, for some reason, blocked. But as the author (or whatever tool was used to generate the article) has taken time to write decent `alt` text, I can still get a good idea of what is going on. Kudos.
I used to share this sentiment (and I’m a web performance consultant by profession so very few people care about performance as much as me!), but when you consider how much calculation we _happily_ let our JS do at runtime, I don’t think forcing CSS to be static/preprocessed is worth it. And that’s not even me taking a swipe at overly-JSsed front-end; I’m talking about any runtime work that JS picks up.
Is preprocessed CSS faster? Yes. Is it meaningfully faster? Probably not.
A firm here in my city once got all of their signage printed and installed _before_ securing the social media handles they’d put on them. The Instagram username they’d opted for was actually literally impossible to register as it contained a special character. That was about six years ago. The signs are still up.
Point 13, ironically, reminds me of one of the best bits of writing[1] I ever did. I somehow lost an entire near-complete draft[2] of an article, so I had to write it again from scratch. It came out much, much better than the original.
I’m on-site with a client in The Hague this week—the food and drink in this city is phenomenal, so these paintings definitely still ring true for me at least.
My guess, as someone who doesn’t know the answer but works closely in this field, is that the potential downside (i.e. privacy/security) was much greater than the actualised benefit (i.e. performance).
Safari (who make a big deal about being privacy-conscious) was the first to introduce cache partitioning, looking into it as far back as 2013[1]; Chrome followed in 2020 and Firefox in 2021[3]. One thing I know, anecdotally, to be a strong motivator among browser vendors is ‘X is doing it, why aren’t we?’
You are correct that this is an optimisation only available to H2+, but optimising to the H/1.x use-case is a use-case not worth optimising for—if one cared about web performance that much, they wouldn’t be running H1/.x in the first place.
I vividly remember this happening. Firstly, because I was an affected customer and I had to cancel all of my debit/credit cards days before a two-week work trip to SF, but secondly…
I was approached by BA to tender for a web performance project. I was excited because, at the time, I had Gold status with BA and I used the site on a weekly basis—I knew exactly where and why it was slow simply through using it so much!
The RFP deadline was short—really short. So, I spent the bulk of a vacation in Croatia writing up my proposal. When I was meant to be lounging by the pool or chugging Malvasia, I was buried in my laptop putting together my pitch. I got it done in time, fired it over, only to be told ‘we are focusing on web security now; this project is on hold’. Then, a few days later, the news broke.
![](https://csswizardry.com/img/css/masthead-small.jpg_ — csswizardry.at.hn
--- meet.hn/city/gb-Leeds
Socials: - csswizardry.at.hn - bsky.app/profile/csswizardry.com - github.com/csswizardry - instagram.com/csswizardry - linkedin.com/in/csswizardry - csswizardry.com - x.com/csswizardry ---