GitHub finishes moving from CSS-in-JS to CSS Modules, cutting render time
Victoria Shinder2 min readGitHub's engineering blog described on 25 September how the site moved its styling from CSS-in-JS to CSS Modules, a migration that started in its Primer design system and ended with the whole of github.com running on CSS Modules as of June 2026.
The motivation was performance. As the number of components on some pages grew from 2023, the CSS-in-JS approach meant styles were initialised on the client, server-side rendering slowed as style collection moved there, and style updates grew with every component on the page. CSS Modules keep styles in a CSS file next to each component, scope class names locally by default, and need no runtime on the client or server. According to the post, once Primer's components were migrated by December 2024, server-side rendering took 55% less time and component initialisation 25% less.
The harder part was the rest of GitHub. Teams had customised Primer components for years through an sx prop, and at its peak there were about 7,760 of them to migrate. GitHub built a wrapper library so existing sx usage kept working while new code imported the migrated components directly, then converted the codebase package by package. A rotation of eight engineers migrated 6,419 props over six months with a VS Code plugin and a codemod, seeing server-rendering gains of 1% to 22% on some pages; the last 895 were removed in three weeks by two engineers using Copilot coding agents. Seven themes, each with a high-contrast variant, then had to be decoupled from styled-components before the dependency could go. Every step was behind feature flags - including, the post says, removing the dependency itself.
What it means
The headline number belongs to the design system; the lesson belongs to the migration. GitHub checked that visual regression snapshots were identical between old and new styles, rolled each change out first to the team, then to staff, then to everyone, and kept the old path working until nobody used it. That is slow, and it is how a large product changes its foundations without users noticing.
The detail about the final 895 props is also worth reading carefully: the automation helped most at the end, when the remaining cases were known and the patterns well established, not at the start.