Gate partialFallback behavior behind partialPrefetching flag#96074
Merged
acdlite merged 1 commit intoJul 22, 2026
Conversation
Contributor
Stats from current PRWarning No stats were collected for Webpack because its stats job did not complete (it failed, was cancelled, or timed out). The results below only cover the bundlers that finished. ✅ No significant changes detected📊 All Metrics📖 Metrics GlossaryDev Server Metrics:
Build Metrics:
Change Thresholds:
⚡ Dev Server
⚡ Production Builds
📦 Production Builds (Webpack) (Legacy)📦 Production Builds (Webpack)
📦 Bundle SizesBundle Sizes⚡ TurbopackClient Main Bundles
Server Middleware
Build DetailsBuild Manifests
🔄 Shared (bundler-independent)Runtimes
📎 Tarball URLCommit: 0246bdc |
Contributor
Tests PassedCommit: 0246bdc |
`partialFallback` is an internal flag in the build output that controls
the behavior of ISR. When it's enabled, in a Cache Components app, pages
that are not generated at build time are upgraded to a full ISR entry
upon the first request.
This is a useful feature but there's a risk it could lead to an
explosion in ISR costs, because even a prefetch request is sufficient to
trigger an upgrade.
The desired behavior is that we only trigger an upgrade for an actual
navigation request, or if a link opts into prefetching with the
`prefetch` prop.
Currently there's no way for ISR to differentiate between a shell
prefetch request (no prefetch prop on the link) and an actual prefetch
(`prefetch={true}`). The plan is to introduce additional configuration
to the build output that specifies which headers should trigger which
operations.
So by default, this PR turns the `partialFallback` flag back off until
the new mechanism is available to us.
However, for apps that opt into Partial Prefetching, we will continue to
set `partialFallback` to true. That's because in a Partial Prefetching
app, per-link prefetch requests are always opt-in. So even without
additional support at the ISR behavior, we avoid an unexpected surge in
ISR costs by not sending the prefetching request in the first place.
There will still be a single request per distinct route (not per
distinct URL!), which we will optimize later.
acdlite
force-pushed
the
acdlite/gate-partial-fallback-on-partial-prefetching
branch
from
July 22, 2026 18:44
39ee69b to
0246bdc
Compare
acdlite
changed the title
partialFallback behavior behind partialPrefetching flag
acdlite
marked this pull request as ready for review
July 22, 2026 20:48
gnoff
approved these changes
Jul 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
partialFallbackis an internal flag in the build output that controls the behavior of ISR. When it's enabled, in a Cache Components app, pages that are not generated at build time are upgraded to a full ISR entry upon the first request.This is a useful feature but there's a risk it could lead to an explosion in ISR costs, because even a prefetch request is sufficient to trigger an upgrade.
The desired behavior is that we only trigger an upgrade for an actual navigation request, or if a link opts into prefetching with the
prefetchprop.Currently there's no way for ISR to differentiate between a shell prefetch request (no prefetch prop on the link) and an actual prefetch (
prefetch={true}). The plan is to introduce additional configuration to the build output that specifies which headers should trigger which operations.So by default, this PR turns the
partialFallbackflag back off until the new mechanism is available to us.However, for apps that opt into Partial Prefetching, we will continue to set
partialFallbackto true. That's because in a Partial Prefetching app, per-link prefetch requests are always opt-in. So even without additional support at the ISR behavior, we avoid an unexpected surge in ISR costs by not sending the prefetching request in the first place. There will still be a single request per distinct route (not per distinct URL!), which we will optimize later.