Runtime CSS-in-JS performance pitfalls in SSR Next.js

WHAT THIS TESTS Whether you grasp that runtime CSS-in-JS does real work in the browser on every render, and how that interacts badly with SSR and React Server Components in Next.js.

A GOOD ANSWER COVERS Runtime libraries such as styled-components or Emotion build and serialize style objects at render time, then inject style tags into the DOM. That adds JavaScript bundle weight and main-thread execution that competes with hydration. During SSR you must collect the styles generated on the server and inline the critical CSS in the initial HTML; otherwise the client renders before styles are attached and users see a flash of unstyled content. In the Next.js App Router this is harder because Server Components do not execute client runtime, so the library must be wrapped in a client boundary and use a style registry hooked into useServerInsertedHTML. There is also a risk of duplicated style computation across server and client and of re-serialization on prop changes.

COMMON WRONG ANSWERS Treating CSS-in-JS as free. Ignoring the flash of unstyled content entirely. Forgetting that App Router Server Components cannot run a runtime library. Claiming hydration is unaffected by style injection.

LIKELY FOLLOW-UPS How does a zero-runtime library like Linaria or vanilla-extract avoid these costs? What does useServerInsertedHTML do? Why might CSS Modules or Tailwind sidestep the problem? How do you measure the hydration cost?

ONE CONCRETE EXAMPLE A dashboard with hundreds of styled components re-serializes styles on every theme toggle, spiking main-thread time and delaying interactivity. The team wraps the provider in a client component with a registry that flushes collected styles via useServerInsertedHTML, eliminating the unstyled flash, then migrates the hottest components to vanilla-extract so their CSS is extracted to a static file at build time, removing runtime serialization and shrinking the JavaScript shipped to the browser.