mirror of
https://github.com/hanzoai/next.js.git
synced 2026-09-24 17:00:51 +00:00
Andrew ClarkandGitHub
a0446c5a82
This is the final step in the segment bundling system. The first commit ensured correctness when inlining hints are stale or unavailable. The second taught the build-time hint computation to identify which segments can be omitted and how parent data flows through disabled segments to static descendants. This commit makes the server and client act on those decisions: small static segments are combined into a single prefetch response rather than fetched individually. This step is inherently larger than the previous ones. We moved as much complexity as possible into the earlier commits — the hint bits, the pass-through logic, the metadata assignment, the safety invariants — but the server output changes and the client scheduling changes need to land together to keep behavior coherent. ### Unified response model The brute-force inlining path that previously existed is removed. Both the old per-segment behavior and the brute-force "inline everything" mode are now modeled in terms of the size-based system: - **Per-segment (flag off):** each segment's response contains only its own data. This is the behavior when `prefetchInlining` is not enabled, or when a segment exceeds the size threshold. - **Size-based (flag on):** setting `prefetchInlining: true` uses default thresholds (2KB per-segment, 10KB total budget). Segments below the threshold are bundled into their children's responses. Segments above it get standalone responses. - **Brute-force (infinite thresholds):** setting the thresholds to infinity means every segment is bundled into a single response for the entire route. The size-based heuristics should make this unnecessary. There is no separate code path for any of these modes. The same server and client logic handles all three — the only difference is the hint bits computed at build time. ### Metadata bundling The metadata (head/viewport) is bundled into the response of whichever segment is responsible for it, avoiding a separate metadata fetch in most cases. On routes with runtime prefetch, the first runtime segment is responsible — its response already includes the metadata. On purely static routes, the first page terminal with budget room gets the metadata. If no terminal has room, the metadata is fetched separately. ### Independent metadata prefetching When navigating between sibling routes under a shared runtime layout, the layout is already cached and no runtime segment request is needed. But the metadata (head) may differ between siblings. This commit ensures the metadata is always prefetched independently via a runtime request when `SubtreeHasRuntimePrefetch` is set on the route tree, even when no runtime segments need fetching. ### Skipping unnecessary static output Segments with `instant = false` or runtime prefetch enabled don't benefit from static prefetch responses. Now the server skips generating static output for these segments entirely, reducing build output size. The client also skips creating cache entries for them. They still participate in the bundle chain as null placeholders — parent data flows through them to static descendants — but no actual data is produced or fetched. This skipping is NOT gated by the `prefetchInlining` feature flag. The hints that drive it (`HasRuntimePrefetch`, `PrefetchDisabled`) are computed at build time and embedded in the route tree regardless of bundling. ### Test plan The prefetch-inlining test suite covers: basic inlining chains, large segments that break chains, deep chains, parallel routes, dynamic routes with concrete params, runtime prefetch boundaries (both leaf and pass-through), `instant = false` segments, stale hint recovery, metadata assignment, the `instant = false` at root fallback, independent metadata prefetching for routes with runtime data in the head, and runtime parallel slot pass-through. Each test verifies both the hint computation (via snapshot assertions) and the actual navigation behavior (prefetch via link accordion, then navigate to confirm data was prefetched).
Next.js
Getting Started
Used by some of the world's largest companies, Next.js enables you to create full-stack web applications by extending the latest React features, and integrating powerful Rust-based JavaScript tooling for the fastest builds.
- Visit our Learn Next.js course to get started with Next.js.
- Visit the Next.js Showcase to see more sites built with Next.js.
Documentation
Visit https://nextjs.org/docs to view the full documentation.
Community
The Next.js community can be found on GitHub Discussions where you can ask questions, voice ideas, and share your projects with other people.
To chat with other community members you can join the Next.js Discord server.
Do note that our Code of Conduct applies to all Next.js community channels. Users are highly encouraged to read and adhere to it to avoid repercussions.
Contributing
Contributions to Next.js are welcome and highly appreciated. However, before you jump right into it, we would like you to review our Contribution Guidelines to make sure you have a smooth experience contributing to Next.js.
Good First Issues:
We have a list of good first issues that contain bugs that have a relatively limited scope. This is a great place for newcomers and beginners alike to get started, gain experience, and get familiar with our contribution process.
Security
If you believe you have found a security vulnerability in Next.js, we encourage you to responsibly disclose this and NOT open a public issue.
To participate in our Open Source Software Bug Bounty program, please email [email protected]. We will add you to the program and provide further instructions for submitting your report.