GitHub deleted styled-components, cutting server render time by 55%
Most frontend teams adopted CSS-in-JS a few years ago because it felt modern and kept the styles next to the code. GitHub spent the next three years backing out of that decision. As of June 2026, github.com runs entirely on CSS Modules, and styled-components and styled-system are fully removed from the product. The Primer team published the story on September 25, 2026, and the measured numbers make it worth reading even if you never touched styled-components.
The problem was runtime, not style
styled-components injects styles through a JavaScript runtime that runs on both the client and the server. In a small app that cost is invisible. GitHub is not a small app. Certain pages had grown dense with components, and the team says the runtime started showing up in both client and server performance. That is why the migration began in 2023. The fix was not another styling library. It was plain CSS, colocated as modules. CSS Modules let each component ship its styles as native CSS next to its JavaScript, with no runtime anywhere. The browser simply receives a stylesheet that ships with the page HTML, and there is no code left to execute it on the server or the client.
They went to the boring option
Teams that leave CSS-in-JS often reach for a fresh library, a utility framework, or some new abstraction. GitHub went the other way, to the least glamorous destination. CSS Modules give you scoped class names, colocated files, and zero runtime, which is exactly the combination that removes the cost they were trying to escape. There is nothing novel about the endpoint. That is the point. The win is deleting a runtime, not adopting something shinier.
The migration ran in stages
A site as large as GitHub cannot change its styling in one release, so the work ran behind feature flags, converting components one at a time and proving each change in production before rolling it out. Phase one converted the Primer design system's own components. By December 2024 every Primer component had moved, and the team measured a 55 percent reduction in the time to server-side render a page and a 25 percent reduction in the time for a page's components to initialize. Those are the headline numbers, and they came from moving the design system first, long before the wider codebase was touched.
The sx prop was the real obstacle
The design system was the easy half. GitHub also ran on the sx prop, a Primer feature that let any team inject inline style objects directly into a component. The authors call it the best and worst part of CSS-in-JS, and they are right. Removing CSS-in-JS from Primer did not remove sx from the thousands of components built on top of it. To keep the site working during the transition, the team built a wrapper library, @primer/styled-react, so legacy sx code kept functioning while newly migrated components could be imported directly for the gains. The sx cleanup began in April 2025 with a peak of roughly 7,760 props to migrate. An in-house engineer, Ian Sanders, built a VS Code plugin to convert props one at a time, and an internal codemod handled whole-file migrations. A rotating team of eight engineers pushed through 6,419 of those props over six months, gaining 1 to 22 percent in server-side render speed on the pages where it mattered.
Two engineers and some agents finished it
Then work paused. GitHub's attention moved to Copilot, to the coding agent and code review features, and the remaining props sat in the queue. When the team returned in April 2026, only 895 props were left. Two engineers, aided by Copilot coding agents, cleared all of them in three weeks. The last dependency was theming: seven themes, each with a high-contrast variant, wired through styled-components utilities. The underlying variables already lived in CSS via the @primer/css package, so decoupling the JavaScript theming layer took about two more months of migration, rollout, and flag work. After that, sx, styled-components, and styled-system were all removable. styled-components had by then announced it was entering maintenance mode, which the team read as a quiet confirmation that they had been moving the right direction.
What this means for a normal team
Read this as a data point, not a weekend project. GitHub had years, feature flags, a codemod, and a design system to isolate first. If your codebase is smaller, the core lesson still transfers: measure the runtime cost of your styling approach before you celebrate it, and prefer the option that deletes code from the critical path. CSS Modules are a fine, boring destination, and so are plain CSS with cascade layers or native nesting. The specific tool matters less than the direction, which is toward styles that cost nothing to execute. The team is honest about the cost, too. Their account mentions a few hiccups along the way, and the effort spanned multiple years with a mid-project pause. The last 10 percent of a migration like this, theming and the scattered inline props, is where the real weeks go.
The story is less a rebuttal to CSS-in-JS than a reminder that the runtime cost is real, that it compounds as a product grows, and that the exit is plain CSS. GitHub spent three years of engineering to remove a library that was slowing down its own pages. For most teams the cheaper move is to check whether that cost is actually showing up in your numbers before you start, and to begin with the design system, the way they did.
Comments