Files
Andrew ClarkandGitHub dfa7f4f713 Attempt static prefetch before resorting to runtime (#96095)
If we're reasonably confident that a segment can be prefetched
statically without omitting data that would have been included during a
runtime prefetch (e.g. cookies), the client should attempt prefetch the
segment statically instead of going straight to a runtime request.

The decision for whether to do this is based on the
ShouldAttemptStaticPrefetch added in previous steps.

If it turns out the static response is not sufficient, then it will fall
back to a runtime request.

This makes prefetching cheaper for pages that are fully statically
renderable. We can make the optimization better in the future with more
reliable per-segment computation of the ShouldAttemptStaticPrefetch, but
the current approach should at least work for fully static pages, which
is what's most important.

This optimization applies during both the Shell phase and the
Speculative phase of the prefetching algorithm.
2026-07-28 11:51:29 -04:00

33 lines
980 B
TypeScript

import { Suspense } from 'react'
// A page that observes its searchParams: like cookies, search params hang
// during a static prerender but resolve during a runtime one, so observing
// them is recorded as a runtime-data access in the shell stage of every
// prerender. The route tree prefetch never carries the static-prefetch hint
// and the client should go straight to a runtime shell prefetch without
// attempting a static one.
async function SearchContent({
searchParams,
}: {
searchParams: Promise<{ q?: string }>
}) {
const { q } = await searchParams
return <div id="search-content">{`Query: ${q ?? 'none'}`}</div>
}
export default function Page({
searchParams,
}: {
searchParams: Promise<{ q?: string }>
}) {
return (
<main>
<p id="page-content">Search params page shell text</p>
<Suspense fallback={<p id="search-loading">Loading query...</p>}>
<SearchContent searchParams={searchParams} />
</Suspense>
</main>
)
}