GitHub cut server-side rendering 55% by trading CSS-in-JS for CSS Modules

GitHub has explained how it made its site faster by sending browsers more CSS, not less. According to the GitHub Blog, replacing the CSS-in-JS setup behind its Primer design system with build-time CSS Modules cut server-side rendering time by 55% and component initialization time by 25% — and the change landed without visibly breaking the product.

When runtime styles stopped scaling

Primer is the component library behind much of GitHub's interface, from buttons to banners to breadcrumbs. As the GitHub Blog tells it, the trouble surfaced in 2023, when component counts on certain pages began to climb sharply. The CSS-in-JS approach used at the time generated and collected styles at runtime, and that cost grew with every component: initial page loads slowed because styles were initialized in the client, server-side rendering degraded as style generation shifted off the browser, and style updates expanded unwieldily as pages accumulated more components.

The team's conclusion was that any replacement had to eliminate runtime style processing on both the client and the server — and that it had to be delivered without breaking GitHub along the way.

More CSS, no runtime

The replacement they chose was CSS Modules. Component styles are written as ordinary CSS files sitting next to the component's JavaScript, class names are local by default to avoid the collisions that come with global selectors, and everything compiles into static stylesheets delivered with the page's HTML. The browser downloads more CSS than a runtime solution would produce, but nothing needs to be computed or injected when the page loads or renders.

A component-by-component rollout

Because the change touched every Primer component plus every GitHub component built the same way, the team migrated incrementally. For each component, they added a file translating the existing styles into CSS Modules, put the new styles behind a feature flag, used visual regression tests to confirm snapshots matched the CSS-in-JS output, then widened the flag from the Primer team to GitHub staff and finally to all users. The old CSS-in-JS technique kept working throughout for GitHub code that still relied on it.

By December 2024, every Primer component had been converted. The measured results, per the GitHub Blog: 55% less time to server-side render a page, and 25% less time for the components on a page to initialize.

Retiring the sx prop

The remaining obstacle was the sx prop, Primer's inline-object mechanism for styling and customizing components. The GitHub Blog credits it with strong TypeScript support tied to design tokens and convenient colocation with component code — but also a high runtime cost driven by dynamic inline objects, and scaling problems as the number of sx-using components on a page grew.

To decouple the two problems, the team built @primer/styled-react, a wrapper package that let migrated components keep accepting sx. Code importing through the wrapper behaved exactly as before, while code importing directly from @primer/react picked up the performance gains immediately.

The company-wide cleanup began in April 2025 with roughly 7,760 sx props to migrate and concluded in May 2026. Engineer Ian Sanders built a VS Code plugin to assist with per-prop conversion, and an internal codemod handled entire files; the GitHub Blog describes the work as mostly automated but requiring manual oversight and careful validation. A rotation of eight engineers migrated 6,419 props over six months, with server-side rendering time improving between 1% and 22% depending on the page. When the effort resumed in April 2026, the final 895 props took a team of two just three weeks. Along the way, the announcement that styled-components was entering maintenance mode read to the team as outside confirmation of the direction.

Why it matters

The post is a concrete, measured argument in the long-running CSS-in-JS debate: at GitHub's scale, runtime style generation cost more than the larger static payload that replaced it. The usual instinct that fewer bytes means a faster site is inverted here — shipping more CSS, generated at build time, won decisively on rendering and initialization metrics.

The transferable lessons are in the migration mechanics. GitHub used its design system as the vehicle for a platform-wide change, feature flags and visual regression tests to keep production stable, a compatibility shim so dependent application code didn't block progress, and codemods plus editor tooling to automate a long tail of thousands of call sites. For any web team weighing a similar move off runtime styling, GitHub's numbers — including the pages that only gained a few percent — offer a realistic picture of both the payoff and the effort involved.