Memory‑Leak Mitigation in MUI v5 SSR: Unique Emotion Cache Key vs. Legacy JSS Engine

Goal

Prevent the accumulation of stale CSS nodes that occurs when Material‑UI v5’s Emotion cache is shared across server‑side rendering requests.

Constraint

In a Next.js or other SSR framework, the same Emotion cache instance is reused for every request unless a new cache is created. This leads to memory growth and DOM bloat. The documented fix is to supply a unique cache key or instantiate a fresh cache per request. Alternatively, teams can keep the legacy JSS styling engine, which does not share a cache in the same way.

Unresolved Decision

Which approach—per‑request Emotion cache or legacy JSS—offers the best balance between memory stability, bundle size, and runtime performance for a long‑running SSR application?

Questions

• How does the use of a unique Emotion cache key compare to the legacy JSS engine in terms of memory consumption over successive SSR requests?
• What are the trade‑offs in bundle size and runtime overhead when choosing between a per‑request Emotion cache and the legacy JSS engine?
• How does each approach affect style deduplication and the number of <style> tags inserted into the DOM?