Go back

GitHub shares its experience moving away from CSS-in-JS

How GitHub replaced runtime CSS-in-JS with utility classes and improved bundle sizes, INP and LCP.

GitHub shares its experience moving away from CSS-in-JS

On its engineering blog, GitHub has published a detailed explanation of how it moved key pages from styled-components and runtime CSS-in-JS to server-delivered CSS with utility classes.

The reason is the familiar one: performance. As Primer React (their design system) grew, the generated CSS started to balloon, and the runtime overhead of parsing and injecting styles through JS began noticeably slowing hydration and rendering.

What they did:

  • Ship more CSS, but less JS. They switched to precompiled utility classes and attributes.
  • Removed runtime calculations. Styles are no longer generated on the fly in the user’s browser.
  • Preserved DX. Developers still write React components, but under the hood, atomic classes replace JS functions that generate styles.

The results in numbers:

  • -58% in JS bundle size on the dashboard.
  • -80% in CSS volume (by reusing atomic utility classes instead of duplicating rules for each component).
  • A noticeable boost in INP (Interaction to Next Paint) and LCP metrics.

The main takeaway:

Runtime CSS-in-JS was a great concept for its time and gave DX an enormous boost, but it became a bottleneck for complex products at GitHub’s scale. The trend toward zero-runtime solutions (Panda CSS, StyleX) or traditional/atomic CSS continues.

Read the explanation on the GitHub blog

Copied