Ant Design v6 gates its zeroRuntime win behind five prerequisite upgrades

Start with ConfigProvider, because that is where a v6 migration bites first. Theming in v6 flows through a DesignTokenContext, and when `theme` is undefined the provider layer may be omitted entirely, which lets components remount without warning ^[6]. The dev.to migration writeup reports exactly that happening on its author's team: a lazily loaded theme value was briefly undefined during a render, ConfigProvider tried to read `token` at render time, styles failed and components remounted ^[7]. The fix given is one line, `const tokens = config?.token ?? {}` ^[8]. That line tells you the shape of the API: the theme object is a required input with a default, and it cannot be resolved later.

Now add the prerequisite that is easiest to skip. The guide says to upgrade to the latest v5 first and clear every console deprecation warning, because v6 expects a clean codebase and unresolved deprecations can hide runtime surprises ^[5]. Counting that one, the published checklist puts five gates ahead of the decision about zeroRuntime ^[18]. The performance mode sits last on that list, added only after everything else is settled.

zeroRuntime itself turns off Ant Design's runtime style generation and moves to a pure CSS-variables architecture, buying faster start-up and less JS work at render time ^[9]. The claim attached to it is that this "can dramatically reduce runtime cost and bundle size" ^[19], and no measured figures sit behind that phrase, so there is nothing yet to transfer to your app. The mechanism is still reasonable to reason about: work that was happening in JS moves to build time, so the size of the win scales with how many components render on first paint. It also scales with how static your theming is. If tokens are swapped per user session, the source is explicit that the pattern has to be reworked into precomputed variants, self-injected CSS variables, or theming limited to the variables you can swap at runtime ^[10].

The other audit is your own CSS. v6 refactors internal component DOM in places, so any rule targeting Ant Design's internal classes or element structure needs rewriting ^[13]. The writeup's example is a custom override on `.ant-btn > span` that stopped applying because v6 moved internal spans ^[14]. The recommended replacements are token overrides first, then a documented top-level selector or a component-level class, or a wrapper className you scope your styles to ^[15]. `.ant-btn > span` was always unsupported, even though plenty of production stylesheets treat it as one.

My read, for a codebase already on React 18: take v6 for the CSS-variables theming and the cleaner React baseline, and treat zeroRuntime as a second decision made after the upgrade lands and the selector audit is done. It pays when your theme variants are known at build time. When they are computed per session, you are trading a rewrite of the theming layer for a saving nobody has published a number for ^[19].