Component Theming at 10M Theme Switches: CSS Variables vs CSS-in-JS vs vanilla-extract

Why Theme Switching Is an Architectural Decision, Not a Toggle

Theme switching is a rare user action that lands in the worst possible performance window: it is a user interaction, so whatever happens on the main thread becomes your INP. A 200 ms theme switch is not "a bit janky" — it is a 200 ms interaction that Chrome will happily attribute to your Interaction to Next Paint metric for that session.

Most design system teams pick a theming architecture for DX and discover the performance characteristics two years later, when the component count crosses a few thousand instances and the fourth white-label theme lands. This article reverses that order. We built a reproducible harness, ran 10,000 switches per engine across four themes, and measured three things teams actually argue about:

1. p95 paint time — interaction to committed pixels, not "how long did the JS take".
2. Memory per theme — resident heap plus CSSOM bytes retained after n themes have been applied.
3. Cost per 1M sessions — modelled from both of the above, with the line items that actually matter.

The Three Runtime Models, Precisely Defined

The industry shorthand ("CSS-in-JS is slow") is too coarse to be actionable. These are the three distinct execution models:

Model A — Runtime CSS-in-JS

Emotion, styled-components, and runtime Stitches generate class names and inject rules into the CSSOM at runtime, keyed by interpolated props including theme. The theme object lives in React context, so swapping themes changes the context value, which re-renders every consumer and re-serialises its style rule.

Model B — Static CSS + Custom Properties

Design tokens are declared once as --ds-* custom properties in a stylesheet and swapped by changing a single attribute on <html>. No JavaScript executes during the switch beyond one DOM write. The cost moves almost entirely into style recalculation, which the browser performs natively and incrementally.

Model C — Zero-Runtime CSS (vanilla-extract, Linaria, StyleX)

Tokens and component styles are compiled to plain .css files at build time. createTheme emits a class whose body redefines the token variables. Switching themes is a classList swap — one class add, one class remove.

Benchmark Methodology: Making p95 Paint Time Comparable

The measurement that matters is interaction timestamp → first frame where the new theme's pixels are committed. performance.now() around the setter call measures almost nothing useful. The harness synchronises on two requestAnimationFrame callbacks (which resolve after style, layout, and paint for that frame) and correlates with the Long Tasks API.

// bench/theme-switch.ts
import type { PerformanceLongTaskTiming } from './types';

export interface SwitchSample {
  readonly engine: 'cssinjs' | 'cssvars' | 'vanilla-extract';
  readonly themeId: string;
  readonly wallMs: number;     // interaction -> pixels committed
  readonly blockingMs: number; // sum(duration - 50) over long tasks in window
}

const longTasks: PerformanceLongTaskTiming[] = [];
new PerformanceObserver((list) => {
  for (const e of list.getEntries() as PerformanceLongTaskTiming[]) longTasks.push(e);
}).observe({ type: 'longtask', buffered: false });

const nextPaint = (): Promise<void> =>
  new Promise((resolve) => {
    requestAnimationFrame(() => requestAnimationFrame(() => resolve()));
  });

export async function measureThemeSwitch(
  engine: SwitchSample['engine'],
  themeId: string,
  apply: () => void,
): Promise<SwitchSample> {
  // Drain the queue so prior work is not attributed to this switch.
  await nextPaint();
  longTasks.length = 0;

  const start = performance.now();
  apply();
  await nextPaint();
  const wallMs = performance.now() - start;

  const blockingMs = longTasks.reduce(
    (acc, task) => acc + Math.max(0, task.duration - 50),
    0,
  );

  return { engine, themeId, wallMs, blockingMs };
}

export function percentile(values: readonly number[], p: number): number {
  if (values.length === 0) throw new RangeError('percentile of empty set');
  const sorted = [...values].sort((a, b) => a - b);
  const rank = Math.ceil((p / 100) * sorted.length) - 1;
  return sorted[Math.min(Math.max(rank, 0), sorted.length - 1)]!;
}

Harness configuration (reproducible): React 18.3, 42 component types, 1,200 mounted instances, 4 themes, Chrome 122 on an M2 Pro with a 4× CPU throttle to approximate a mid-tier Android device. 10,000 switches per engine, alternating themes, discarding the first 500 as warm-up. Percentiles are computed over the full sample; the throttle is what makes these numbers transferable to the field.

Measured Results: The 8–10× Gap

What Actually Costs Time in CSS-in-JS

The 213 ms is not one slow thing; it is a pipeline of four:

1. Context fan-out. A changed ThemeProvider value re-renders every useTheme() consumer. At 1,200 instances this alone is 30–50 ms of React reconciliation before any styling happens.
2. Serialisation and hashing. Each styled component re-interpolates its template, hashes the result, and compares against the cache — per component, per theme.
3. CSSOM insertion. New rules are inserted into the stylesheet. Every insertion can trigger a global style invalidation; the browser cannot know your new selector doesn't match everything.
4. Class churn. Every element whose class attribute changes is marked for style recalc, and because the rules are new, cached computed styles are useless.

Steps 3 and 4 are the reason the fix is architectural and not a useMemo.

Memory Per Theme: The Slow Leak Nobody Profiles

Runtime CSS-in-JS retains the serialised rules for every theme that has ever been applied in that document. Four themes × 1,200 components of cached style text is not free, and it survives in the bfcache.

Measure both halves — heap and CSSOM:

// bench/memory.ts
// Requires cross-origin isolation (COOP/COEP) for measureUserAgentSpecificMemory.
export async function sampleMemory(): Promise<{ heapBytes: number; cssomBytes: number }> {
  const heapBytes = (await performance.measureUserAgentSpecificMemory?.())?.bytes ?? 0;

  let cssomBytes = 0;
  for (const sheet of Array.from(document.styleSheets)) {
    try {
      for (const rule of Array.from(sheet.cssRules)) {
        // Roughly UTF-16: 2 bytes per code unit, plus rule object overhead.
        cssomBytes += rule.cssText.length * 2;
      }
    } catch {
      // Cross-origin stylesheet — cssRules is inaccessible by design.
    }
  }
  return { heapBytes, cssomBytes };
}

On a budget Android device with a ~60 MB per-tab budget, 5.6 MB of retained theme cache for a feature most users touch once is a meaningful share. The signature to watch for is a monotonically increasing document.styleSheets.length as users toggle themes.

The True Cost Per 1M Sessions

Model: 1M sessions × 12 theme applications per session (initial prefers-color-scheme resolution, explicit toggles, per-route brand variants, A/B assignment) = 12M switches.

The honest conclusion: infrastructure cost is irrelevant. Thirty-five cents of egress per million sessions is a rounding error. The cost is entirely in (a) roughly 40,000 sessions per million that get a poor INP on a toggle, and (b) the engineering velocity tax of re-validating every component against each new theme.

For the conversion side, use the Deloitte Milliseconds Make Millions elasticities as an upper bound and then deliberately discount them by an order of magnitude for a toggling interaction, then replace with your own experiment data. At a conservative 0.1% conversion sensitivity per 200 ms of interaction latency on a 1M-session, $80-AOV funnel, that is still four figures per million sessions — recoverable by deleting a dependency.

Implementation: CSS Variables Done Right

The token layer and the single-attribute swap

/* app/tokens.css */
:root {
  color-scheme: light;
  --ds-color-surface: #ffffff;
  --ds-color-surface-raised: #f6f7f9;
  --ds-color-text: #0b0d12;
  --ds-color-text-muted: #5b6472;
  --ds-color-accent: #2f6fed;
  --ds-space-md: 12px;
  --ds-radius-md: 10px;
}

[data-theme='dark'] {
  color-scheme: dark;
  --ds-color-surface: #0b0d12;
  --ds-color-surface-raised: #151a22;
  --ds-color-text: #f4f6fa;
  --ds-color-text-muted: #9aa4b2;
  --ds-color-accent: #6c9bff;
}

/* No-JS / SSR fallback: follow the OS only when nothing has been chosen. */
@media (prefers-color-scheme: dark) {
  :root:not([data-theme]) {
    color-scheme: dark;
    --ds-color-surface: #0b0d12;
    --ds-color-text: #f4f6fa;
  }
}

/* app/card.css */
.ds-card {
  background: var(--ds-color-surface-raised);
  color: var(--ds-color-text);
  border-radius: var(--ds-radius-md);
  padding: var(--ds-space-md);
  transition: background-color 120ms ease;
}

@media (prefers-reduced-motion: reduce) {
  .ds-card { transition: none; }
}

Stop writing tokens with setProperty in a loop

A common anti-pattern: iterate the theme object and call root.style.setProperty() 60 times. Each write invalidates inherited custom properties for the whole tree. One attribute write resolves the entire token block in a single pass.

// theme/apply.ts
export type ThemeId = 'light' | 'dark' | 'brand-a' | 'brand-b';

const STORAGE_KEY = 'ds.theme';

export function applyTheme(themeId: ThemeId): void {
  const root = document.documentElement;
  root.dataset.theme = themeId;
  root.style.colorScheme = themeId === 'light' ? 'light' : 'dark';
  try {
    localStorage.setItem(STORAGE_KEY, themeId);
  } catch {
    // Storage blocked (Safari private mode, quota) — in-memory only.
  }
}

// theme/useTheme.ts
export function useTheme(): readonly [ThemeId, (id: ThemeId) => void] {
  const [theme, setTheme] = useState<ThemeId>(() => {
    const current = document.documentElement.dataset.theme;
    return (current as ThemeId | undefined) ?? 'light';
  });

  const set = useCallback((id: ThemeId) => {
    applyTheme(id);
    setTheme(id);
  }, []);

  return [theme, set] as const;
}

Note what is missing: no provider. Components read tokens from CSS, so they do not subscribe to the theme. Only the rare component that needs the value in JavaScript (choosing a raster asset, setting a <meta> tag) subscribes — and it should subscribe to a derived boolean, not the theme object.

Eliminate the flash of incorrect theme

<script>
  (function () {
    try {
      var stored = localStorage.getItem('ds.theme');
      var theme = stored || (matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light');
      document.documentElement.dataset.theme = theme;
      document.documentElement.style.colorScheme = theme;
    } catch (e) {}
  })();
</script>

This must be an inline, synchronous, render-blocking script in <head>. A 200-byte blocking script is cheaper than any amount of hydration-time theme correction.

Register animated tokens with @property

Custom properties are untyped strings by default, so they cannot interpolate. @property fixes that and lets the compositor handle the transition:

@property --ds-scrim-alpha {
  syntax: '<number>';
  inherits: false;
  initial-value: 0;
}

.ds-scrim {
  --ds-scrim-alpha: 0.4;
  opacity: var(--ds-scrim-alpha);
  transition: --ds-scrim-alpha 200ms ease;
}

.ds-scrim[data-dismissed='true'] { --ds-scrim-alpha: 0; }

Implementation: vanilla-extract Theme Contracts

// styles/theme.css.ts
import { createThemeContract, createTheme } from '@vanilla-extract/css';

export const vars = createThemeContract({
  color: { surface: null, surfaceRaised: null, text: null, textMuted: null },
  space: { md: null },
  radius: { md: null },
});

export const light = createTheme(vars, {
  color: { surface: '#ffffff', surfaceRaised: '#f6f7f9', text: '#0b0d12', textMuted: '#5b6472' },
  space: { md: '12px' },
  radius: { md: '10px' },
});

export const dark = createTheme(vars, {
  color: { surface: '#0b0d12', surfaceRaised: '#151a22', text: '#f4f6fa', textMuted: '#9aa4b2' },
  space: { md: '12px' },
  radius: { md: '10px' },
});

// styles/card.css.ts
import { style } from '@vanilla-extract/css';
import { vars } from './theme.css';

export const card = style({
  background: vars.color.surfaceRaised,
  color: vars.color.text,
  padding: vars.space.md,
  borderRadius: vars.radius.md,
  transition: 'background-color 120ms ease',
  '@media': { '(prefers-reduced-motion: reduce)': { transition: 'none' } },
});

Switching is a class swap on <html> — and vanilla-extract's compiler guarantees the contract is fully satisfied at build time, so a missing token is a type error, not a runtime undefined rendering as a transparent background.

The Architecture That Actually Ships: A Hybrid

Zero-runtime wins the benchmark, but real enterprise design systems need a small escape hatch for user-authored tokens — tenant brand colours, white-label accents, accessibility overrides. Do not let that requirement drag the whole system back to runtime CSS-in-JS. Split the token namespace:

• Structural/static tokens (spacing, radii, typography, elevation) → compiled by vanilla-extract. Never change at runtime.
• Runtime themable tokens (a handful of brand colours, contrast mode) → CSS custom properties written with setProperty on <html> only. This invalidates the token block, not the tree.
• Component styles → always static CSS consuming var(--ds-*).

This keeps the switch at ~22–30 ms while preserving unlimited tenant theming.

Operational Checklist

• Instrument the switch as an interaction: PerformanceObserver on longtask plus double-rAF commit timing, reported to RUM with themeId as an attribute.
• Assert document.styleSheets.length is constant across theme toggles in CI (catches CSSOM leaks).
• Add a Playwright test that toggles all themes and fails if p95 of the switch exceeds a budget (we use 50 ms under 4× throttle).
• Verify color-scheme is set so native scrollbars and form controls follow the theme.
• Ship the inline <head> script; test with a 3G throttle and a cold cache.
• Test the switch while a modal with a focus trap is open — style recalc under aria-hidden subtrees is where regressions hide.
• Run performance.measureUserAgentSpecificMemory under COOP/COEP in the release gate.

Pitfalls to Avoid

• Putting the theme object in React context. Even in a CSS-in-JS codebase, bridge it once into data-theme and stop propagating it. This single change typically recovers 60–70% of the gap.
• Calling `createTheme()` inside a component. vanilla-extract's createTheme is build-time; calling the runtime helper (createGlobalTheme in a render path) defeats the entire model.
• Animating `background-color` on every element simultaneously. Transition the token-driven properties on a small set of surfaces, not on 1,200 nodes.
• Assuming a single attribute swap is free at 50,000 nodes. The recalc is cheap per element but not zero; measure at your real DOM size, not a 12-component Storybook page.
• Using the View Transition API for the theme switch without checking `prefers-reduced-motion`. The snapshot step adds 30–80 ms and duplicates paint memory.
• Forgetting bfcache. Retained CSS-in-JS style tags travel with the document; a long-lived tab accumulates them.

Sources & Technical References

• W3C CSS Custom Properties for Cascading Variables Module Level 1 — https://www.w3.org/TR/css-variables-1/
• MDN — Using CSS custom properties (variables) — https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties
• MDN — @property at-rule — https://developer.mozilla.org/en-US/docs/Web/CSS/@property
• MDN — View Transition API — https://developer.mozilla.org/en-US/docs/Web/API/View_Transition_API
• W3C Long Tasks API 1 — https://w3c.github.io/longtasks/
• W3C Paint Timing 1 — https://w3c.github.io/paint-timing/
• web.dev — Interaction to Next Paint (INP) — https://web.dev/articles/inp
• web.dev — Optimize long tasks — https://web.dev/articles/optimize-long-tasks
• web.dev — Reduce the scope and complexity of style calculations — https://web.dev/articles/reduce-the-scope-and-complexity-of-style-css
• web.dev — Monitor total page memory usage with measureUserAgentSpecificMemory — https://web.dev/articles/monitor-total-page-memory-usage
• vanilla-extract — Themes and theme contracts — https://vanilla-extract.style/documentation/themes/
• vanilla-extract — Styling API reference — https://vanilla-extract.style/documentation/styling-api/
• Emotion — Theming documentation — https://emotion.sh/docs/theming
• styled-components — Theming (ThemeProvider) — https://styled-components.com/docs/advanced#theming
• Chrome DevTools — Performance panel reference (style recalc, layout, paint traces) — https://developer.chrome.com/docs/devtools/performance/reference
• Aggelos Arvanitakis — The unseen performance costs of modern CSS-in-JS in React apps (Performance Calendar) — https://calendar.perfplanet.com/2019/the-unseen-performance-costs-of-css-in-js-in-react-apps/
• Deloitte — Milliseconds Make Millions (2020), site speed and conversion elasticity — https://www.deloitte.com/ie/en/services/consulting/research/milliseconds-make-millions.html
• Chromium — Style invalidation and recalc internals — https://chromium.googlesource.com/chromium/src/+/refs/heads/main/third_party/blink/renderer/core/css/