Do the arithmetic on the headline figure before you touch a route. Removing 700ms of TTFB down to 60-80ms is 620 to 640ms gone, an 89 to 91 percent cut, or somewhere between nine and twelve times faster [12]. That is the cache-hit path, and only the cache-hit path. The directive caches results rather than execution [4], so a miss still runs the expensive fetch in full before the value gets serialised into the RSC payload and folded into the static shell.
Which puts the deploy behaviour at the centre of the estimate. Cache keys include the build id, and a new deploy resets cache entries [7]. Every release therefore buys at least one uncached render per cached route [13], and the first visitor after each deploy gets the ~700ms render the refactor was supposed to delete. The guide's own note that `use cache: remote` is for teams needing a shared durable store across instances with very high hit rates [9] implies the default store is per instance, so that minimum cold count scales with how many instances you run, not how many routes you cached.
The before-and-after metric list is TTFB, FCP and LCP for the shell, and time-to-interactive [10]. Cache hit rate is not on it [14]. Hit rate is the variable that decides whether 60-80ms is your median or your best case, and it is the one number the guide never asks you to record.
The real cost of adoption is not the directive, it is the boundary. You cannot read `cookies()`, `headers()` or `searchParams` inside a `'use cache'` scope; those reads must sit inside a Suspense-wrapped dynamic subtree or the build errors [6]. Any route that currently reaches for request-time context wherever it likes has to be reorganised so that personalised work lives below the boundary and the cacheable work lives above it. That is a data-flow rewrite of the route, and it is why the guide's sequence is fetch once, pass the promise down into the cached boundary, then wrap the slow subtree in a skeleton [1].
Credit where it is due: failing at build time is the right failure mode. A silent stale-personalisation bug is the thing you would fear from a caching directive, and this one refuses to compile instead [6]. The conservative rollout advice matches that: wrap only the heavy server boundary you control and expand later [11], with `cacheLife()` or `cacheTag()` reserved for data that needs a TTL or on-demand invalidation, since the default shell lifespan is deemed adequate for many UI routes [8].
So the mechanism is legible and the guardrails are real. The evidence for the payoff is thinner: one route, described only as a fully dynamic server render replaced by a cached boundary plus a small Suspense shell, with no route size, no traffic profile and no methodology given, plus the observation that the janky transitions frustrating product owners went away [3]. The supplied text stops mid-phrase at "Per-user, highly personalized con" [15], which is exactly where the guidance on unsuitable routes would have been. Treating that single before-and-after as a forecast for your own routes is the part of this recommendation nobody has earned yet.
