Look at what the setter does after mount, because that is where the claim lives. Stock React re-runs the component function, builds a new element tree, diffs it against the old one, and commits the differences [4]. The compiled path instead walks the dependency graph: each binding that lists the mutated state cell in `dependencies` recomputes its `read` and writes the result into one text node or one attribute, with no render, no reconciliation and no commit phase [7]. The repo carries a runtime test that mounts the compiled and baseline versions side by side and asserts the compiled one updates with zero React renders [8]. A test that asserts a zero is easier to trust than a chart.
React still owns the first mount, and `render` is still emitted, so hydration, refs and devtools keep seeing an ordinary component [9]. That is the part I would defend at review. The fast path is an addition to a mounted React tree, and the fallback is the original component rather than a rewritten one [2].
The proof obligation is narrow. A component qualifies only when the compiler can establish one stable host element tree and a mapping from every supported state value to a known text or attribute target [10]. Props whose updates carry identity are excluded, which covers objects, arrays, functions and elements, as are `dangerouslySetInnerHTML` and setters called outside a JSX event handler [11]. The complete eligibility table sits in the docs, and reading it before the benchmark is the right order [23].
The one performance-adjacent number supplied is about bundle size. The author measures the runtime premium for direct-bindings-only output at 73.6% smaller than shipping the complete runtime [13], which leaves the minimal premium at 26.4% of the full runtime [14]. That is a floor for the narrowest output the compiler can emit, not a forecast for an application.
The post says it publishes benchmark numbers including the case where the optimisation does nothing [20], and the copy supplied to this desk stops mid-sentence before that table [21]. So here is what would have to be true for any such figure to move to your codebase. Your update traffic would have to be concentrated in components that clear the eligibility bar [10], and reconciliation would have to be the dominant cost of those updates rather than layout, data fetching, or a parent re-rendering above them. The second condition is the one benchmarks usually satisfy by construction and real pages usually do not.
You can at least interrogate your own tree cheaply. Fallback is silent by default, but diagnostics can be switched on, and the messages name the blocking feature, as in the `KeyedList` line stating that dynamic child structures require React reconciliation [16]. Enabling the whole thing is one experimental flag on the renderer [19], any component can be pulled back out with a `"use no compiler"` directive [18], and the framework runs in the browser through WebContainers if you want to poke at it before installing anything [22]. If your hot components land in the fallback list, the benchmark table is describing someone else's component tree.
