Comment by meerita
16 hours ago
I don't know how they perceive the performance. I see 41 network requests. That's 2.1 MB of CSS over the wire, blocking rendering and hurting painting and loading speed. There's 400 KB of Tailwind, 87 KB of general CSS, plus another 200 KB of other general CSS. They need to embrace functional CSS properly. I'm sure they could have a single CSS file under 80 KB that renders everything.
These type of comments often come from a place of arm-chair reasoning where you might not sit on the experience of working hands-on in a large team on a large product. While it’s probably true that X kB sufficient, that amount of performance optimisation is usually not warranted at this scale. Maintaining a design system, working with scoped classes, legacy code, and dealing with the complexities of chunking and probably further challenges we are not aware of from the outside. It seems like a common sentiment on HN (maybe not you in particular) is that engineers should drop everything and work overtime on optimizing performance, when it comes to web apps
This sort of comment has completely lost the forest for the trees.
You’re conflating scale with bloat. At large orgs the problem is that nobody is willing to step back and say “this sucks”. Trying to get this fixed involves getting 6 teams to agree upon something with no clear owner for the outcome and with everyone incentivised for not being blamed if one of the other groups tanks the effort.
> engineers should drop everything and work overtime on optimising performance
No, we’re asking for it to be taken seriously by the organisation. I work in games, and on large projects we usually have a small team (2/3 people of a team of 80-100) who are constantly working on this stuff. Their work is “subjective” improvements but often it’s just building tooling and telling other groups what they need to fix.
I think part of the difference is that in gaming if performance sucks then there's a real community of people who push back and it will affect sales directly. In web development at least for the majority of sites (e.g. not on the level of usage of Github) usually people just stop visiting your site, so you don't see public pushback as much.
If a decent portion of your audience literally cannot even play the game because its performance is too bad or it can't run on their hardware, then that immediately affects your bottom line. And at least until recently, you couldn't really push fixes for it once the game was delivered. And so I think at least a little bit of that mindfullness for performance has carried over to the modern day, though I will say that I do think that performance optimization does seem to subjectively be getting worse even in gaming.
In web dev, while it is true that it affects your bottom line, it's a little bit less obvious. And in the eyes of most management teams that's always something that can be prioritized later since you could always update it after you shipped a feature. Also, there was very much a culture of "the browser will handle it."
Not to mention, most devs are using the hardware that is many times better than their consumers.
2 replies →
And how that happens in gaming? Pretty curious now.
1 reply →
Isn't this backwards? Optimizing assets becomes more important with scale, not less. Not saying it is actually prioritized that way or that it would be easy but IMO the more traffic you have the more important it is to be frugal with bits.
Yeah. Sites like GitHub pay a lot of money every month for servers. At scale, a bit of performance work can save you millions on your bills. And make your site run faster for users at the same time.
> that amount of performance optimisation is usually not warranted at this scale.
Indeed, you need to waste a few years hurting user experience before investing a few years into migration and writing another "improved performance" blog post.
> that engineers should drop everything and work overtime on optimizing performance
The opposite, they should work less instead of more doing a worse job that results in scraping all their output later in a redesign
The beauty of functional CSS is that you can progressively transform everything. GitHub runs on entire modularized codebase, they can clean up the entire codebase within weeks, days if they use agents and see the effects of performance instantly.
The shitty team excuse.
Performance is not complicated. You measure something and compare the numbers. Through my career I have encountered the following failures repeatedly:
* The complete inability to measure things. This is common among people with low social intelligence. Many people in this line of work cannot measure things and form all kinds of bullshit excuses. Cannot do it all as if they are disabled. Sometimes it is laziness, sometimes it’s autism masking, and sometimes it’s stupidity/ignorance where they believe they shouldn’t have to or are superior from convention alone.
* The shitty team argument. It’s common for people to intentionally avoid or discard measures because there is fear superior performance may indicate an operating deficit. The last thing anybody in software wants is to change approach if they are on a shitty team, because corporate developers are allergic to training people. This is often justified by asking what happens if you work on a team or about new hires.
* Throwing performance data away and lying about it. This is very common when performance data provides evidence that current conventions or favorite tools harm performance. If, for example querySelectors measure 100,000 times slower than some other approaches developers will pretend the performance evidence just doesn’t exist.
* Guessing. When people suck at what they do they invent their own performance realities. When people guess at software performance they are supremely wrong more than 80% of the time and tend to be wrong by multiple orders of magnitude.
You’re confidently making a lot of assumptions that don’t generalize.
For example:
> performance is not complicated
Not to mention all your assumptions about the motivations of people who don’t do optimization well. That one can’t possibly generalize.
3 replies →
You measure and improve the metric, but at what cost, when should you stop? Have you worked on a 1mill+ loc web app?
1 reply →
And it's specially easy for the case of CSS: less CSS, more faster.
> This is common among people with low social intelligence
lol What? It's always amusing to me when someone makes absolute claims like "the industry" when having seen < 0.1% of it.
"big company can't make fast website"
nah
Yes, good points, but also with modern LLMs you can vendor the design system around and cut it to the bone on every app. If your organization ships a worse solution than Claude slop, do you really want to stick with it?
FWIW, a very quick look at other comparable sites (what seems to be the main css files):
sourcehut's 128kb raw, and 28kb over the wire.
codeberg is 420kb raw, and 66kb over the wire.
2.1MB is nothing for the user.
2.1MB is a huge most of the world where the internet speeds are not gigabyte etc. Yes, storage wise it's not a lot, but it's extra 5 seconds or so the user needs to wait for the site to load.
There are only a few countries in the world where 2.1 MB extra would add (barely) more than 1 second to site download based on the country’s median internet connection speeds. The vast majority of countries would see less than <100ms from 2.1MB.
And the bigger thing here is that this is all cached after it’s downloaded the first time.
1 reply →
That shows a lot of disrespect for hardware that isn’t yours.
Read Performance Inequality Gap https://infrequently.org/2025/11/performance-inequality-gap-...