next.js

1d14e93c - Cached Navigations: Cache visited fully static pages in the segment cache (#90306)

Cached Navigations: Cache visited fully static pages in the segment cache (#90306) When a fully static page is loaded (via initial HTML or client-side navigation), the segments are now written into the segment cache so subsequent navigations can be served entirely from cache without server requests. Initial HTML: The RSC payload inlined in the HTML is written during hydration via `getStaleAt` + `writeStaticStageResponseIntoCache` with `isResponsePartial: false`, using `FetchStrategy.Full` since all segments are present. A `StaleTimeIterable` (`s` field) is included in the `InitialRSCPayload` during the Cache Components prerender path to provide the stale time. Navigation: The `isResponsePartial` flag from the prepended byte (stripped by `processFetch`) is now also used to determine how segments from `writeStaticStageResponseIntoCache` are cached. For fully static routes (`isResponsePartial: false`), segments are written as non-partial so no dynamic follow-up is needed. The route tree used for cache writes is now always derived from the Flight data itself (via `convertServerPatchToFullTree`), rather than from a pre-existing route cache entry. This guarantees the tree stays in sync with the response and avoids key mismatches between the static stage tree and the per-segment prefetch tree for parallel route slots. When writing the head into the cache, `isHeadPartial` from the server is overridden to `false` for non-partial responses, but only when Cache Components is enabled. This corrects the server's conservative `isPossiblyPartialHead` marking during static generation. Without Cache Components, the server already sends the correct value. Responses without a recognized marker byte (e.g. regular navigations that don't go through the prerender path) are conservatively treated as partial. Partially static pages (where the static stage needs to be extracted via byte-level truncation of the initial HTML Flight stream) will be handled in a follow-up. --------- Co-authored-by: Andrew Clark <git@andrewclark.io>