What happened

Picture a shared elevator in an office tower. Product teams can polish their floors, but if the cabin takes forever to open its doors, no amount of lobby art helps. A design system is that cabin: every screen above it inherits its interaction cost.

Odell picked ten actively maintained libraries (October 2026): React ones include Mantine, Ant Design, Material UI, and React Spectrum; others sit on Lit, FAST, Stencil (Ionic), and more. He measured how long the main thread stayed busy after the click (median of three runs) and the longest stretch the UI stopped responding. He puts a 100ms responsiveness budget next to accessibility on the design-system team’s list.

Country-list open on CPU×4 (React-focused rows from the Status write-up and his post):

Fluent and Carbon were even faster (~60ms). The same Ionic that crushed the dropdown was quick on 100 checkboxes — while MUI finished them in 70ms versus Ant Design’s 421ms. Framework alone did not decide the race: two Lit-based kits diverged by more than 2×, and one library could be slow at one task and fine at the other.

Spectrum’s list is virtualized, yet cutting options in half barely changed open time. Profiling put checkVisibility from React Aria near the top: for each visible option, clear height, read size, force layout again. Odell’s fix sketch — clear heights first, measure once — is filed; a patch is in review.

Same issue, briefly: TanStack Redact, a smaller React/React DOM stand-in for the browser with synchronous render and no time slicing; and TanStack DB 1.0 RC1, an API-stable reactive client data layer with a migration guide. Week background — the lead is the design-system bench.

Why it matters

Product teams often feel “the form is sluggish” but cannot patch a shared Select inside someone else’s package. CI usually watches bundle size, not click response — and users wait on the click. Odell’s line is blunt: performance belongs beside accessibility on the design-system backlog.

The numbers are a risk map, not a shame ranking. MUI opens a long list slower (roughly all ~250 nodes) yet checks boxes faster. Ant Design opens faster via virtualization but pays on checkbox animations. Picking a kit without a load scenario is choosing an elevator by cabin color.

The Spectrum dig shows the bottleneck may not be “React is slow” but a measurement loop in a shared accessibility library. One React Aria ticket can unblock a whole class of apps — elevator motor repair for the building.

In practice

Someone else’s table is a signal. A repeatable test on your components beats quoting theirs.

1. Clone denodell/design-system-performance-tests and run Playwright against your Select / checkbox list with CPU×4.
2. Set a bar: long-list open and bulk actions should not hold the main thread past 100ms without an explicit team decision.
3. In Chrome’s Performance panel, watch Rendering as well as Scripting — write-then-read size loops are classic layout thrashing.
4. For long lists, pair virtualization with accessibility (Ant Design’s hidden copy of the highlighted option), not DOM cuts alone.
5. Do not reduce “design-system performance” to bundle bytes; catch time-to-interactive after the click separately.
6. Before swapping MUI ↔ Ant Design ↔ Mantine, run both scenarios on your data — Odell’s tables show the winner depends on the job.
7. On Spectrum / Aria stacks, watch the option-measurement issue; do not copy that loop into app code.

Takeaway

A design system under real load behaves like a shared elevator: cabin lag hits every floor. Odell’s CPU×4 bench spans tens to thousands of milliseconds and pins a concrete React Aria measurement bug — with tests you can hang on your own components.

React Status #495 also nods at Redact and TanStack DB RC1, but the frontend lesson of the week is simpler: measure the click, not only the kilobytes.