Rendered at 13:43:55 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
meerita 1 days 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.
karolusrex 1 days ago [-]
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
maccard 1 days ago [-]
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.
Jcampuzano2 1 days ago [-]
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.
josephg 15 hours ago [-]
To be really clear, the performance of GitHub’s website has basically always been terrible. I don’t know why. It has bothered be forever. And it’s weird - GitHub doesn’t actually render much content. But it often takes seconds to load that tiny bit of content. I often clone entire repos locally rather than browse them on GitHub just so I don’t have to wait for their webpage.
To continue the comparison, cyberpunk can render night city in 16ms. Which makes me embarassed for GitHub that they can’t render a list of files and a static markdown readme in under a second.
3eb7988a1663 14 hours ago [-]
I would push back on that. It used to be less terrible before they made it all SPA. Now there are all sorts of broken-caching tricks that try to do in-place reloads. I frequently see progress bars incrementing while it is attempt to do a request - while that original redraw is attempting to happen, I can frequently launch a new tab with the same link that will finish rendering before the original.
maccard 20 hours ago [-]
> 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
There is a small, but very vocal group that complain about 30 vs 60fps, and yet there are games that push for 120/240 on consumer hardware (valorant and overwatch both run at very high frame rates on very low specs). As I said, it’s about prioritising it. _Why_ it’s being prioritised doesn’t really matter.
> also there was very much a culture of “the browser will handle it”
That is very clearly still the culture.
> most devs are using the hardware that is many times better than their consumers.
My last work PC was a 32 core 4GHz machine with 256GB RAM, a 4090, and 16TB of NVMe SSD’s with 10GB fibre. Our target platform was 9GB RAM, and an 8 core 1.1GHz processor, yet we still managed (just about).
Xunjin 1 days ago [-]
And how that happens in gaming? Pretty curious now.
maccard 24 hours ago [-]
Frame rates are very important, so we prioritise them. That’s about it. The same “bloat” is often found in internal tooling in games. Unreal is a great example of it, nobody _really_ cared about how long packaging a build took, it got ad hoc improvements, but then epic decided to invest in it and its improved monumentally in the last 2-3 years. (Disclaimer, I worked there when nobody cared and was responsible for some of those as hoc changes)
jchw 1 days ago [-]
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.
josephg 15 hours ago [-]
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.
eviks 1 days ago [-]
> 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
meowface 13 hours ago [-]
The thing is that you're 100% right but the other person is also 100% right.
It is in fact really really really hard to keep things lean and performant over time as you support a more complex multi-purpose web app, but you still have to try. If you try hard enough - especially now in the age of pretty good agents - you can actually thread all of the different needles and keep (perceived and actual) latency low.
meerita 1 days ago [-]
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.
austin-cheney 1 days ago [-]
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.
catlifeonmars 1 days ago [-]
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.
austin-cheney 1 days ago [-]
They are not generalizations. They are frequently repeated observations. The ability to operate from evidence is what determines if you are working with real professionals or children pretenders.
catlifeonmars 1 days ago [-]
Most people are somewhere in the middle, again the dichotomy doesn’t generalize.
vijaybritto 1 days ago [-]
I would like to half agree to this.
Saying "Performance is not complicated" is not wrong. People and the systems set up for an application make it complicated. Its harder to check and verify.
I work in UI performance and the biggest thing slowing me down is always people
kyralis 13 hours ago [-]
Claiming that performance is not complicated, as a blanket statement, is absurd.
There are certainly plenty of performance problems that are not complicated, you're correct that many people do not have the skills necessary to solve even simple performance problems. The connection to social intelligence is a leap that doesn't really follow, though; this feels more like you just trying to dump on people who are missing skills, which isn't usually very helpful.
Regardless, however, there are absolutely performance problems that are complicated. When you're trying to optimize performance in environments constrained by compute, network, disk, and memory, finding the right solutions to reach the right optimum amongst the contributing factors can, in fact, be very much nontrivial. This is especially true if you're working on more general systems for which client use patterns may vary wildly.
karolusrex 1 days ago [-]
You measure and improve the metric, but at what cost, when should you stop? Have you worked on a 1mill+ loc web app?
austin-cheney 1 days ago [-]
You improve performance for a variety of reasons. You stop when you have competing evidence. The other 99% of the time it’s just developers making bullshit excuses.
meerita 22 hours ago [-]
And it's specially easy for the case of CSS: less CSS, more faster.
mexicocitinluez 1 days ago [-]
> 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.
winrid 16 hours ago [-]
"big company can't make fast website"
nah
blfr 1 days ago [-]
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?
DrBazza 1 days ago [-]
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.
panzi 11 hours ago [-]
That's more than 4 times the size of Super Mario World, I believe. Always fascinating how little is done with so much these days.
BobbyTables2 13 hours ago [-]
I thought CSS was originally to simplify hand-written HTML so it could focus more on the content and formatting would be standardized by the CSS stylesheet.
2MB of CSS just sounds insane. What are we even doing here?
FFS, why not just go back to explicitly inlining all the formatting in the HTML itself? I have trouble believing all the CSS is actively used. It’s not like any of this is written by humans these days.
2MB of text - isn’t that roughly half the size of the Christian Bible?
worldsavior 1 days ago [-]
2.1MB is nothing for the user.
asutekku 1 days ago [-]
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.
gdhkgdhkvff 24 hours ago [-]
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.
Using GitHub everyday, I haven't really noticed an improved performance. Actually i'd say pages are becoming slower. Browsing issues with many comments or big PR has a terrible experience as not everything gets loaded
marginalia_nu 1 days ago [-]
Yeah. It used to be unusable on mobile and great on desktop. But desktop has in my experience honestly been slipping pretty bad last few years. Maybe I live too far from the data center or something.
One weird tangentially related thing is checking whether a PR is merge:able after solving a conflict in this repo[1] for some reason takes several minutes. Maybe because there are 1000 commits in the same file. Doesn't seem UI related but weird regardless.
I'm still a bit salty they fiddled with the Lists UI when star'ing a repo and adding it to a list.
The emojis I had at the beginning of the list name don't render anymore (they show up as :eyesore_emoji_name: instead) and the list is sorted alphabetically now instead of by last modified. Also it's one looong list instead of a small scroll-able container like it used to be.
This is on Firefox btw. Now I'm seriously thinking about moving these GitHub "bookmarks" into a separate place like a bookmark manager even if I lose a bit of convenience.
eviks 1 days ago [-]
Unfortunately the original blog post introducing the great CSS-in-JS system being removed is not in the "Related posts" section, would be nice to compare the thinking in the two
efortis 1 days ago [-]
There's room for improvement still. Currently, the production build is using long-dev class names. e.g. `DirectoryContent-module__Box_3__gl6dE` could be compiled to a shorter hash like `gl6DE3a2`.
Personally I don't think this reduction in size is big enough compared to making all css names unreadable and thus very difficult to debug.
It also makes it much more difficult to create personal browser extensions as all css names are now unreadable.
edoceo 18 hours ago [-]
Use a source map, lots of tools do that for the Js and CSS build process.
chrismorgan 23 hours ago [-]
You could also drop the hash part and gain most of that improvement. Or module and hash and do better on compression (because the hash is high-entropy).
${local}: 52610 raw, 7927 br. (Now in practice a few of these are likely to need disambiguation, so it’s probably a tad smaller than realistic.)
Frankly I think ${local} is the right target, with global disambiguation where necessary. For typical systems, I consider the hash approach to be foolish: its value is when interacting with unknown other styles, but when you’re compiling everything you should know everything, so you can disambiguate more selectively and succinctly/compressibly, as JS build tools like Rollup do (in flattening modules with colliding names, you’ll get Foo, Foo$1, Foo$2, &c.).
efortis 22 hours ago [-]
> ${local} is the right target, with global disambiguation where necessary.
How?
---
Another approach is using base52 sequential names, such as `aa, ab, …`. I tried that a few years ago in Webpack, I don't remember but there was an issue, IIRC they weren't deterministic.
chrismorgan 21 hours ago [-]
Compile everything together and you know what names are used. I can’t comment on whether it’s easy or even possible with the specific toolchain in question, but the concept is very straightforward.
NostraDavid 23 hours ago [-]
Try zstandard instead of Brotli - a clearly superior format, IMO. Definitely better than gzip.
The only thing hashing classes achieves is making it difficult for users to use ad blockers and/or custom CSS. I understand why e.g. Meta does it on their sites, but for GitHub it makes no sense.
Onavo 1 days ago [-]
Would you need a source map then for prod debugging?
Starlevel004 1 days ago [-]
Perhaps we should never ever use hashed class names?
Gualdrapo 1 days ago [-]
Once (like a year ago or so) stumbled upon some person's post asking for someone to help them to "fix" some section at their website. It was done !important over !important over !important over !important. Said person was really convinced all it needed was another bunch of !important because apparently that was what ai spit for them, at least at that time
low_tech_punk 1 days ago [-]
You either "improve performance" or "ship more ___", never both.
a11ce 1 days ago [-]
Sometimes, [GitHub] posts a [blog post in which they move away from] some terrible [way of doing things] I've never heard before, and it's a weird indirect way to learn how awful their other [design choices] must be.
And yet, there's been a glaring overflow bug on every repo page if the repo has a sponsor button on Firefox Android for months.
lloydatkinson 1 days ago [-]
Any time I see criticism of CSS in JS, and a move to CSS modules, I get sad they didn’t just do a bit more research. You can have both, while also not shipping any JS runtime for CSS in JS! And with TypeScript support.
At the cost of pretty bad build time performance when the application grows.
We migrated a >1M LOC codebase to CSS Modules from VE for a ~30% build time speed improvement and much better tree shaking on Next.js
nicce 1 days ago [-]
I thought that whole point of CSS in JS was about building the CSS with JS in build time, to get managed and optimized output, who madman runs in in runtime?
c-hendricks 23 hours ago [-]
The idea of an `sx` prop kind of implies runtime. If there's any logic in those objects it can't be pre computed
lloydatkinson 17 hours ago [-]
It seems all the people criticising CSS in JS are doing it at runtime, like styled-component users.
wonnage 16 hours ago [-]
The Achilles heel of this class of library (including stylex, Linaria, etc.) is precedence. You either have to use a runtime and some complicated merging rules (e.g longhand overrides shorthand) or compile every possible combination of the styles at build time.
surlyville 22 hours ago [-]
The performance must also improve because all iDevices on iOS < 16.4 can no longer view GitHub in Safari due to old WebKit. I blame Apple for not allowing Webkit to be updated independently of the iOS firmware.
Thankfully we now have the Reynard Browser (sideload/trollstore) that uses GeckoView so supports more modern web standards.
jay37184 1 days ago [-]
css-in-js? Rofl. Whats next? Html-in-js?
tosti 18 hours ago [-]
What else do you think React was for?
prymitive 1 days ago [-]
Website-from-prompt?
UqWBcuFx6NV4r 1 days ago [-]
Yes.
varun_chopra 1 days ago [-]
Honestly, hats off to them. It's hard to get anything done with Copilot so I'm amazed they even managed to do this.
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.
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.
To continue the comparison, cyberpunk can render night city in 16ms. Which makes me embarassed for GitHub that they can’t render a list of files and a static markdown readme in under a second.
There is a small, but very vocal group that complain about 30 vs 60fps, and yet there are games that push for 120/240 on consumer hardware (valorant and overwatch both run at very high frame rates on very low specs). As I said, it’s about prioritising it. _Why_ it’s being prioritised doesn’t really matter.
> also there was very much a culture of “the browser will handle it”
That is very clearly still the culture.
> most devs are using the hardware that is many times better than their consumers.
My last work PC was a 32 core 4GHz machine with 256GB RAM, a 4090, and 16TB of NVMe SSD’s with 10GB fibre. Our target platform was 9GB RAM, and an 8 core 1.1GHz processor, yet we still managed (just about).
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
It is in fact really really really hard to keep things lean and performant over time as you support a more complex multi-purpose web app, but you still have to try. If you try hard enough - especially now in the age of pretty good agents - you can actually thread all of the different needles and keep (perceived and actual) latency low.
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.
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.
Saying "Performance is not complicated" is not wrong. People and the systems set up for an application make it complicated. Its harder to check and verify.
I work in UI performance and the biggest thing slowing me down is always people
There are certainly plenty of performance problems that are not complicated, you're correct that many people do not have the skills necessary to solve even simple performance problems. The connection to social intelligence is a leap that doesn't really follow, though; this feels more like you just trying to dump on people who are missing skills, which isn't usually very helpful.
Regardless, however, there are absolutely performance problems that are complicated. When you're trying to optimize performance in environments constrained by compute, network, disk, and memory, finding the right solutions to reach the right optimum amongst the contributing factors can, in fact, be very much nontrivial. This is especially true if you're working on more general systems for which client use patterns may vary wildly.
lol What? It's always amusing to me when someone makes absolute claims like "the industry" when having seen < 0.1% of it.
nah
sourcehut's 128kb raw, and 28kb over the wire.
codeberg is 420kb raw, and 66kb over the wire.
2MB of CSS just sounds insane. What are we even doing here?
FFS, why not just go back to explicitly inlining all the formatting in the HTML itself? I have trouble believing all the CSS is actively used. It’s not like any of this is written by humans these days.
2MB of text - isn’t that roughly half the size of the Christian Bible?
And the bigger thing here is that this is all cached after it’s downloaded the first time.
Download speed isn't the only thing that matters
One weird tangentially related thing is checking whether a PR is merge:able after solving a conflict in this repo[1] for some reason takes several minutes. Maybe because there are 1000 commits in the same file. Doesn't seem UI related but weird regardless.
[1] https://github.com/MarginaliaSearch/submit-site-to-marginali...
The emojis I had at the beginning of the list name don't render anymore (they show up as :eyesore_emoji_name: instead) and the list is sorted alphabetically now instead of by last modified. Also it's one looong list instead of a small scroll-able container like it used to be.
This is on Firefox btw. Now I'm seriously thinking about moving these GitHub "bookmarks" into a separate place like a bookmark manager even if I lose a bit of convenience.
If you use Vite:
Besides download size, smaller names improve parsing speed too.
It also makes it much more difficult to create personal browser extensions as all css names are now unreadable.
Rudimentary experiment on https://github.githubassets.com/assets/te.1288ac5c9584fbf2.m... on replacing /(?<module>[A-Za-z0-9_-]+)__(?<local>[A-Za-z0-9_-]+)__(?<hash>[A-Za-z0-9_]{5})\b/:
${module}__${local}__${hash} (original): 72967 raw, 10993 br.
${module}__${local}: 68459 raw, 8867 br.
${hash}: 48754 raw, 8189 br.
${local}: 52610 raw, 7927 br. (Now in practice a few of these are likely to need disambiguation, so it’s probably a tad smaller than realistic.)
Frankly I think ${local} is the right target, with global disambiguation where necessary. For typical systems, I consider the hash approach to be foolish: its value is when interacting with unknown other styles, but when you’re compiling everything you should know everything, so you can disambiguate more selectively and succinctly/compressibly, as JS build tools like Rollup do (in flattening modules with colliding names, you’ll get Foo, Foo$1, Foo$2, &c.).
How?
---
Another approach is using base52 sequential names, such as `aa, ab, …`. I tried that a few years ago in Webpack, I don't remember but there was an issue, IIRC they weren't deterministic.
The only thing hashing classes achieves is making it difficult for users to use ad blockers and/or custom CSS. I understand why e.g. Meta does it on their sites, but for GitHub it makes no sense.
https://xkcd.com/2071/
https://vanilla-extract.style/
Thankfully we now have the Reynard Browser (sideload/trollstore) that uses GeckoView so supports more modern web standards.