Improving site performance by shipping more CSS

Improving site performance by shipping more CSS github.blog

How we fully migrated github.com away from CSS-in-JS.

94 points•torutofu•4 days ago•72 comments•

#css #performance #shipping #improving #fully #com #github #migrated

72 comments

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.

karolusrex4 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

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

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

eviks4 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

meowface3 days 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.

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

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

BobbyTables23 days 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?

panzi3 days 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.

billyhoffman2 days ago

I mean I'm all for smaller CSS and faster web performance, but comparing the size / information density of the binary data of a 36 year old video game console with the verbose human readable text of a DSL used to control presentation is a bit unfair.

worldsavior3 days ago

2.1MB is nothing for the user.

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

jonhohle3 days ago

That shows a lot of disrespect for hardware that isn’t yours.

troupo3 days ago

Read Performance Inequality Gap https://infrequently.org/2025/11/performance-inequality-gap-...

jenadine4 days ago

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

[1] https://github.com/MarginaliaSearch/submit-site-to-marginali...

aquariusDue3 days ago

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.

eviks4 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

efortis4 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`.

If you use Vite:

  css: {
    modules: {
      generateScopedName: mode === 'production'
        ? '[hash:base64:8]'
        : '[name]__[local]___[hash:base64:5]',
      }
    }

eviks4 days ago

The improvement would be shipping human-readable structure to allow easier user overrides, not that hash abomination

robin_reala4 days ago

Those class names surely gzip better than hashes over the wire?

efortis4 days ago

Here's a comparison using `brotli --best` on my app.

   53K _long.css
   38K _short.css

   11K _long.css.br
  8.9K _short.css.br

Both, dev and prod, have hashes because that's part of what CSS Modules uses to avoid collisions.

Besides download size, smaller names improve parsing speed too.

notpushkin4 days ago

This.

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.

Onavo4 days ago

Would you need a source map then for prod debugging?

Starlevel0043 days ago

Perhaps we should never ever use hashed class names?

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

https://vanilla-extract.style/

wonnage3 days 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.

fgkramer3 days ago

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

nicce4 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-hendricks3 days 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

lloydatkinson3 days ago

It seems all the people criticising CSS in JS are doing it at runtime, like styled-component users.

Read the full thread on Hacker News →

72 comments

Related stories