Measured Time Budgets Show SSR Moves the Cost Into an FCP-to-TTI Canyon
Teams tune TTFB with SSG or streaming while TTI stays stuck on hydration, and a single ISR config can mean 30-second staleness on hot pages but 45-minute staleness on cold ones. These measurements make both failures visible before deployment and separate what actually needs changing: client JS execution, not render location.
Eight rendering strategies share one page model in a deterministic Node time-budget script: 2400 components, 9000 DOM nodes, 700KB raw / 230KB gzip JS, 40ms RTT, and 4x CPU throttle. The output separates the blank period (navigation to first content) from the canyon (first content to interactive). CSR leaves users staring at white for 945.8ms but only 120.0ms of unclickable content. SSR cuts FCP to 541.4ms and turns the canyon into 1346.8ms; TTI lands at 1888.2ms, 822.5ms later than CSR. Streaming and SSG move TTFB forward (by 229ms and 264ms respectively) without moving the canyon at all. The deciding account is JS: transfer 153.3ms, parse 210.0ms, hydration 1215.0ms.
A 4000-click simulation of the canyon finds 9.8% of clicks before the root listener exists do nothing; queued clicks wait 417.6ms on average, 827ms at P95, and 1179ms worst-case. Islands, RSC, and resumability shrink the canyon to 151.9ms, 91.1ms, and 39.0ms by cutting hydration work. Island economics follow a 'constant + interaction ratio' curve: one framework runtime is 46KB gzip no matter how few components are interactive, three frameworks ship 138KB gzip, and five frameworks equal the full-hydration JS payload.
Under ISR, the same revalidate=60 config produces a 90.9x spread between hot and cold pages: 30s average staleness on the Top1 page, 45.5min on the coldest of 10000 Zipf-distributed pages. 9933 pages revalidate as often as SSR would and gain 24.3 minutes of extra staleness. Revalidation storms only appear under event traffic: 60 concurrent renders at 200 req/s versus 0.22 at normal rates. Request coalescing protects the origin; SWR protects users. On-demand invalidation uses the same 24 origin hits/day as revalidate=3600 and holds worst-case staleness at 2s instead of 1h.
Render location is easy to judge by TTFB and FCP because those numbers appear early in a trace; TTI arrives later, so 'SSR made the page faster' can survive without anyone checking interaction latency.
ISR's freshness numbers are two different averages depending on what is weighted: page-weighted staleness is 24.2 minutes, traffic-weighted is 7.7 minutes. A dashboard that averages the wrong axis will certify either version as healthy.
SSR versus CSR is a unit-cost comparison, not an architectural identity. The model solves for a 0.15 ms/node crossover, so pages dominated by static DOM can favor SSR while JS-heavy pages can favor CSR.
Islands and RSC still pay a fixed framework floor that no build optimization removes; every added framework consumes the savings, and three runtimes already exceed the entire island payload of a single-framework page.
One percent hydration mismatch is invisible to a mean-based performance board but hits a thousand users per day with a 660ms reset; that failure mode is variance, and the standard aggregate hides it.