Count work, not file extensions.
GitHub reports that its previous CSS-in-JS setup initialized styles in the client, collected styles during server rendering, and became more expensive as component counts grew. Primer's move to CSS Modules removed that runtime styling behavior. The styles became regular stylesheet output linked from the page.[1]
The headline is deliberately awkward. GitHub shipped more CSS and measured less execution work. After Primer components moved to CSS Modules, GitHub reports 55 percent less server-rendering time and 25 percent less component initialization time. Those are GitHub's measurements for its system. They are not a promise for every React application.[1]
A smaller JavaScript bundle is not the whole win. The browser also stops manufacturing styles during the trip.
Local scope survives the move.
CSS Modules keep class and animation names local by default. At build time, an imported module produces a mapping from local names to generated global names. That preserves a useful part of component styling without requiring a styling runtime in the request path.[2]
This is one option, not a universal winner. A product with highly dynamic values, embedded shadow roots, or a different build setup may choose another route. The decision should follow an instrumented page, a cache plan, and the team's maintenance needs.
The bridge made deletion possible.
GitHub could not remove thousands of sx props in one change. Primer added @primer/styled-react, a temporary package whose wrappers kept sx and styled-system props working over the migrated components. Its README marks the package and components as deprecated because removal is the intended finish line.[3]
That is the sharp part of the design. A compatibility layer should have a counter, owners, and a deletion condition. Without those, a bridge becomes a second permanent styling system.
Migration speed still needs proof.
GitHub says an eight-engineer rotation migrated 6,419 props over six months with a VS Code extension, a codemod, and manual validation. In a later phase, two engineers and coding agents moved the remaining count from 895 to zero in three weeks. The report also says individual pages saw server-rendering improvements between 1 and 22 percent during that work.[1]
Automation changed throughput. It did not remove the review problem. GitHub used visual regression snapshots, staged feature-flag rollout, and performance signals. A fast codemod without those witnesses can turn one known runtime cost into a pile of spacing and theme regressions.
Do not confuse transfer weight with runtime weight.
The Hacker News thread quickly challenged the amount of CSS delivered by github.com. That criticism asks a separate, valid question. A migration can reduce server and browser execution while leaving unused CSS, chunking, cache behavior, or render blocking to tune later.[5]
Keep both ledgers. Measure compressed CSS bytes, request count, cache reuse, and render blocking. Measure server render time, hydration or initialization work, long tasks, and style recalculation. One number cannot describe both the cargo and the engine.