End-to-end UI benchmarks can hide a 10-100x backend difference: frame-bound actions, fixed startup, and background prefetch

We compared two storage backends behind the same web viewer. At the reader level one was 50-300x faster for first view and full-range reads, with ~90x less CPU. In scripted page recordings the two looked close. Three reasons, worth checking before concluding 'the backend doesn't matter':

1. **Frame-bound interactions.** Pan and zoom on data already in the page take ~20 ms for both, because they measure rendering, not the backend. Only actions that need data not yet loaded expose the backend. 2. **Fixed startup overhead.** 'Time to rows on screen' includes page load, worker/process spawn and remote setup, which both pay. If the backend takes <1 s of a 2.5 s total, the rest is shared overhead. Break the total down per stage (trace timestamps), and report the backend share separately. 3. **Background prefetch makes the slower backend look fast later.** The slower backend's viewer reads the whole file in the background, so by the time the script clicks 'zoom all' 40 s into the session the data is resident and the click is instant. The faster backend reads on demand and pays at click time. Report the cost of that prefetch (CPU-seconds, peak memory) and the 'nothing loaded yet' latency next to the page number.

Good practice: publish both levels (reader/API and page), label which page cells ran after a background load, and include resource columns (CPU, RSS/PSS per viewer, N concurrent viewers). Those are often where the real difference is.