GitHub explains its CSS Modules migration: performance is more than download size

GitHub published an engineering report on 25 September 2026 describing github.com’s move from CSS-in-JS to CSS Modules. The Primer team said the site reached 100% CSS Modules in June 2026 after a gradual migration that took several years.

The report’s title — “Improving site performance by shipping more CSS” — is deliberate. The argument is not that unlimited stylesheet growth is harmless. It is that sending prepared CSS with a page can cost less than generating and managing styles through JavaScript at runtime.

Where CSS-in-JS became expensive

GitHub says component counts began to rise sharply on some pages in 2023. Styles took longer to initialise in the browser, server-side rendering performance declined, and style updates became more expensive as the number of components increased.

CSS Modules let engineers keep a CSS file beside a component’s JavaScript source while treating class names as local by default. That reduces global selector collisions. More importantly for GitHub’s architecture, the approach removed the client and server runtime work previously required to create styles. The rules could instead be bundled into stylesheets and sent with the page.

A migration controlled by flags and tests

GitHub did not replace every component in one release. For each component, the team added a CSS Modules implementation and a feature flag that could switch between the old and new styling paths. Visual regression tests compared snapshots to check that the two versions rendered consistently.

Rollout moved from the immediate team to GitHub staff and finally to all users. That sequence gave engineers a way to detect faults early and reverse a limited change without rolling back the entire site.

The migration also went beyond syntax. GitHub had to remove sx, styled-components and styled-system from dotcom and separate its theming system from JavaScript utilities. The site supports seven themes, each with a high-contrast variation, so theme compatibility was a distinct engineering problem.

How to interpret GitHub’s numbers

The company says that after Primer components were migrated by the end of 2024, server-side rendering time fell by 55% and page-component initialisation time fell by 25%. These are GitHub’s measurements within its own architecture. They are not universal benchmarks and do not guarantee identical gains for another application.

A different site may have different bottlenecks, caching behaviour, traffic patterns and bundle composition. A larger CSS download can still be harmful, especially on slow connections, even when runtime work is reduced.

The reusable lesson

Teams choosing between CSS-in-JS and CSS Modules should measure runtime cost, SSR, caching, transfer size, team workflow and test coverage together. GitHub’s result should not be copied without local evidence.

The most transferable part is the migration method: small steps, feature flags, visual regression testing, and measurements before and after each change. Those controls made it possible to replace a foundational styling system without turning the work into one high-risk release.

Sources

• GitHub Engineering: Improving site performance by shipping more CSS
• CSS Modules project documentation