Five frameworks, one store, and a benchmark that measures when the button works

Someone rebuilt the same commerce store five times, in Kudzu, Astro with React islands, React Router, TanStack Start and Next.js App Router, and published the benchmark as open source ^[1][2]. The interesting part is not which one won but the choice of yardstick: the harness treats time-to-first-text as close to useless and asks instead when a control actually works, and what the browser had to download to get there ^[10].

The reasoning is sound. All five implementations emit complete HTML ^[8], so the content arrives at roughly the same moment in every version ^[13]. The Largest Contentful Paint element is generally a product image, and the image bytes are identical between implementations by design, which means LCP does not separate these builds in this fixture ^[9]. A benchmark whose dominant measurement is the same JPEG five times is a benchmark about a JPEG. The gap that does open up is between seeing the interface and being able to use it reliably ^[14].

So the instrumentation is behavioural: contentReady, actReady, stepLatency, navigation latency, dropped early clicks, total bytes transferred across the session, JavaScript downloaded per route, and behaviour when JavaScript is delayed or partly unavailable ^[10]. The author explicitly refuses framework-internal "hydration complete" signals and lets the browser decide ^[11]. The main run is Slow 4G with a 4x CPU slowdown, replaying the same interactions five times per implementation ^[12]. Six routes are covered: home, search with filtering and sorting, collections, product details, policy content, and checkout ^[5], with product options, cart adds, filtering, sorting, forward and back navigation all in the scripted path ^[6]. That is thirty route builds held to one behavioural contract ^[24][7].

The comparative medians are presented as tables that the text supplied to us does not carry; the only absolute figure stated in prose is that Kudzu's compiler-generated behaviour is available after roughly 250 ms, with the React-based implementations waiting on more client-side machinery to arrive and execute ^[25][15][16]. Treat the ordering as the claim and the exact milliseconds as unverified here. Two methodological details are worth more than the table anyway. JavaScript is measured from observed network activity rather than by crawling the import graph, because Astro can pull island runtime code through dynamic imports that a naive static crawler misses ^[17]. And session transfer is measured with prefetching included and the cache carried forward, on the argument that users navigate and reuse rather than reload isolated pages ^[21].

To the author's credit, the result is not a sweep. On listing to product navigation, React Router and TanStack Start beat Kudzu's document navigation, and the post says plainly that removing a persistent application runtime does not make every operation faster, it moves where the cost sits ^[19][20]. Kudzu's own search route ships more JavaScript than its siblings because it needs keyed-list behaviour, while the other routes do not pay for it ^[18].

The obvious caveat: the benchmark was written by Kudzu's author, who says the goal was not a synthetic fixture Kudzu could win ^[4][23]. That is why the open-sourcing matters more than the numbers.

Watch whether anyone outside the project runs the harness and reports back, and whether actReady and stepLatency survive contact with hostile reviewers, since a metric that only its inventor can compute is not yet a metric. Also watch the degradation matrix: six capabilities under three conditions, one of them JavaScript fully blocked ^[22]. That table, not the 250 ms, is where a commerce team's risk actually lives.