Switching Primer to CSS Modules reduces client and server style costs

Switching to CSS Modules reduces client- and server-side CSS work on component-heavy pages, lowering runtime compute and page-load risk — but it requires engineering time and a careful migration to avoid breakage.

What actually changed

GitHub’s Primer Design System moved away from its previous CSS-in-JS approach and adopted "CSS Modules". The engineering post says the team made the change because their CSS-in-JS pipeline began to slow initial page loads (styles were initialised on the client), worsen server-side rendering performance as style collection shifted, and become harder to manage as component counts on pages increased. The Primer team chose CSS Modules to use native CSS features and to avoid the client and server costs the old solution was imposing.

Who it affects

This matters most for teams that: maintain a shared component library, render many components on the same page, or use server-side rendering where style collection is on the critical path. If your site has few components per page or you do not see client or SSR style-related slowdowns, the performance benefits described are less likely to justify a migration. Teams already committed to CSS-in-JS for developer ergonomics or dynamic style composition should weigh the trade-offs against expected runtime savings.

What it costs, and what it replaces

What it replaces: the announcement explicitly replaces the repository’s CSS-in-JS solution with CSS Modules for Primer’s components.

What it costs: the GitHub post does not state a monetary price or provide an estimate of engineering hours. The visible costs in the announcement are operational and engineering: time to refactor components, the risk of regressions during migration, and the work needed to keep GitHub itself stable while changing the styling system. The post emphasises avoiding breakage during migration but does not describe the migration tooling or processes used.

What we don't know

• How many engineering hours GitHub spent on the migration.
• Whether GitHub used automated codemods or manual refactors.
• The impact on bundle size or CSS payload after the switch.
• Changes to the build pipeline or CI times caused by CSS Modules.
• How developer ergonomics (authoring, theming, runtime composition) compared before and after.
• Any third-party compatibility issues encountered during migration.

What to do next

1. Run a targeted audit: measure initial load time, Time to First Paint, and SSR render time for the pages that render many components, and log whether style initialisation contributes to delays.
2. Prototype one page or one component: convert a small, high-impact page to CSS Modules and compare client CPU, SSR timing and developer effort. Use this to estimate migration hours and to check for regressions.
3. Decide by metric: switch at scale only if the prototype shows a meaningful reduction in client or server rendering cost and the estimated engineering time fits your budget and risk tolerance.