Your route has a loading.tsx. The skeleton is supposed to paint immediately. Instead, the browser sits on a blank document for the length of one upstream API call, then the whole page arrives at once. The Network panel shows a single HTML response with no early chunk. The Performance panel shows nothing on the Main track until after that call resolves.

The usual suspect is a slow generateMetadata. That diagnosis is often right, but the fix people reach for — caching the fetch, adding a revalidate — misses the actual mechanism. In the App Router, metadata is not a head-tag side effect that runs alongside rendering. It is a render-phase dependency. Until you decide whether the shell needs it, you are tuning the wrong thing.

The shell is the contract

React’s server API documentation defines the shell precisely: “The part of your app outside of any <Suspense> boundaries is called the shell.” It “determines the earliest loading state that the user may see” (react.dev, renderToPipeableStream). The onShellReady callback “fires right after the initial shell has been rendered,” and React streams additional content after it, replacing loading fallbacks with inline scripts.

So the shell is not “the page.” It is the minimum tree that must resolve before any bytes leave the server. Everything inside a <Suspense> boundary can arrive later. Everything outside it is on the critical path by definition.

That gives you the only question that matters for a slow route: does the shell need this value to render? Not “how do I cache this fetch.” Whether the shell depends on it at all.

Why metadata is different from ordinary page data

Next.js documents the ordering directly: “Resolving generateMetadata is part of rendering the page” (Next.js docs, generateMetadata). It is not a parallel pass. It is a step in the render.

The same page explains the two outcomes:

If the page can be prerendered and generateMetadata doesn’t introduce dynamic behavior, the resulting metadata is included in the page’s initial HTML. Otherwise the metadata resolved from generateMetadata can be streamed after sending the initial UI.

And it explains why the function is Server Component only: “metadata must be resolved on the server before the page component is rendered.” That sentence is the whole problem. The framework’s design intent is that metadata is known before the page renders. When your generateMetadata awaits a slow upstream call, you have put that call in front of the page render, not beside it.

The crawler branch means there is no global switch

Here is where most advice goes wrong. You cannot simply “move metadata off the critical path” as a site-wide refactor, because Next.js makes the blocking-versus-streaming decision per request based on the user agent.

From the streaming documentation:

For bots that only scrape static HTML, and cannot execute JavaScript like a full browser, such as Twitterbot, Next.js resolves generateMetadata before streaming UI, and metadata is placed in the <head> of the initial HTML. Otherwise, streaming metadata may be used. Next.js automatically detects user agents to choose between blocking and streaming behavior.

Read that carefully. For a non-JS crawler, the framework will block on your metadata regardless of how you structure the route. For a browser, it may stream. You do not control that branch from your component code.

The practical consequence: this is a per-route classification problem, not a global setting. A marketing page that must serve correct Open Graph tags to Twitterbot will pay the metadata cost on the crawler path by design. A logged-in dashboard that no crawler will ever index has no reason to. Treating them the same is the mistake.

The fix that is actually supported

Two documented moves, in order of preference.

1. If the value is not request-dependent, delete the function

The docs are explicit: “If metadata doesn’t depend on request information, it should be defined using the static metadata object rather than generateMetadata.” A static export const metadata removes the question entirely — there is no await, no render-phase dependency, nothing to block on.

This is the most common accidental critical-path metadata. Teams reach for generateMetadata because the title needs a template or the description comes from a CMS field that changes at build time. If the value does not vary per request, the static object is the documented path and the latency problem disappears.

2. Keep uncached data out of the shell

If the value genuinely varies per request, the next question is whether the shell needs it. Often the real blocker is not the metadata call itself but a shared data read it depends on — the same uncached fetch that also sits in a layout.

The loading.js documentation is blunt about this case:

If the layout accesses uncached or runtime data (e.g. cookies(), headers(), or uncached fetches), loading.js will not show a fallback for it. Without Cache Components: Navigation blocks until the layout finishes rendering.

And the prescribed remedy: “To ensure instant navigation, move uncached data fetching from layout.js into page.js, or wrap the runtime data access in your layout in its own <Suspense> boundary.”

This is the structural fix. If your layout reads cookies() or an uncached fetch, the skeleton never shows, and fixing generateMetadata alone will not move the shell. The layout blocks navigation before metadata is even reached.

One caveat worth internalizing: only data read from a source that activates a Suspense boundary — such as a Promise read with use — will suspend during rendering. “Suspense does not detect data fetched inside an Effect or event handler” (react.dev). Wrapping a component in <Suspense> does nothing if the component fetches in an effect.

Streaming changes the error contract

This is the part teams discover after they ship. Once the response body starts streaming, the headers are already gone. The docs state it plainly: “When streaming, a 200 status code will be returned… Because the response headers have already been sent to the client, the status code of the response cannot be updated.”

Next.js compensates for the SEO case by injecting a <meta name="robots" content="noindex"> tag into the streamed HTML when a 404 page is streamed, so search engines will not index the URL even though the HTTP status is 200. That handles indexation. It does not handle compliance, analytics, or any downstream system that reads the status code.

If you need a real 404, the existence check has to happen before the first Suspense fallback renders. The docs are specific: “The response body starts streaming when a Suspense fallback renders (for example, a loading.tsx) or when a Server Component suspends under a Suspense boundary. Place notFound() before those boundaries and before any await that may suspend.”

This is a routing decision, not a metadata one. It belongs in your proxy or in a fast pre-check, not in generateMetadata.

Measure the boundary, not the code

The claim “metadata is off the critical path” is only meaningful if a trace shows it. Reading the source will not tell you, because the crawler branch and the layout-blocking caveat both change the answer per route.

Use the Chrome DevTools Performance panel. Record load performance with the Record and reload button: “DevTools first navigates to about:blank to clear any remaining screenshots and traces. Then DevTools records performance metrics while the page reloads and then automatically stops the recording a couple seconds after the load finishes” (Chrome DevTools Performance reference).

Throttle CPU and network to match your field data before you trust the result. Then read the Main track. The panel “represents main thread activity in a flame chart. The x-axis represents the recording over time. The y-axis represents the call stack.” You are looking for one thing: does the metadata work — the fetch, the serialization, the head construction — appear before or after first paint?

If it appears after, the shell rendered without it and the refactor worked. If it appears before, you moved code without moving the boundary. The trace is the only evidence that settles it.

For the payload side, the Network panel gives you the response size and the timing of the first chunk. A blocked shell shows one HTML response arriving after the full metadata round-trip. A streamed shell shows an early chunk with the skeleton, then later chunks. The gap between first byte and last byte is your shell latency.

A decision rule

For each route, ask in order:

1. Does the value vary per request? If no, use the static metadata object. Done.
2. Will a non-JS crawler need this metadata in the initial HTML? If yes, the blocking behavior is by design and you should optimize the fetch, not the structure. If no, continue.
3. Does the shell depend on this value to render? If yes, the value is on the critical path and you should treat its latency as shell latency. If no, structure the route so the shell renders without it.
4. Is a layout reading uncached or runtime data? If yes, that is your blocker, not generateMetadata. Move the fetch to page.js or wrap it in its own Suspense boundary.
5. Does the route need a real 404 status? If yes, the existence check must run before the first Suspense fallback. Put it in the proxy.

Then verify with a throttled load trace. The trace is the only thing that distinguishes a real fix from a plausible one.

FAQ

Does generateMetadata always block the shell?

No. Next.js documents that metadata “can be streamed after sending the initial UI” when the page cannot be prerendered without dynamic behavior, and that the framework “automatically detects user agents to choose between blocking and streaming behavior.” For non-JS crawlers it resolves metadata before streaming UI. For browsers it may stream. You do not control the branch from component code.

Why does my loading.tsx not show a skeleton?

Most likely a layout in the same segment is reading uncached or runtime data. The docs state that in that case loading.js will not show a fallback and navigation blocks until the layout finishes rendering. Move the uncached fetch into page.js or wrap the runtime access in its own Suspense boundary.

Can I force metadata to stream?

There is no documented switch. The behavior is determined by whether the page can be prerendered without dynamic behavior and by the detected user agent. The lever you have is structural: keep the shell free of the metadata dependency so the framework has something to stream.

Does streaming metadata hurt SEO?

The Next.js documentation states that “since streaming is server-rendered, it does not impact SEO,” and that for non-JS crawlers metadata is resolved before streaming and placed in the initial HTML. The framework handles the crawler case for you. What streaming does change is the HTTP status code contract, which is a separate concern.

What about notFound() inside generateMetadata?

The docs note that redirect() and notFound() can be used inside generateMetadata. But if the response has already started streaming, the status code cannot be updated. Place notFound() before any Suspense boundary and before any await that may suspend if you need a real 404 status.

The version pin

This article describes behavior documented in Next.js App Router (the generateMetadata and loading.js reference pages, current as of the Next.js 16.x documentation) and React’s renderToPipeableStream server API. The streaming-versus-blocking decision is user-agent dependent and is not a stable API surface — verify against the docs for the version you have pinned before restructuring a route.

Your dashboard has been open for forty minutes. The interactions that felt instant at minute two now take a visible beat to respond. You open the Chrome Task Manager, enable the JavaScript memory column, and watch the live number climb in a staircase pattern that never comes back down. Nothing in the React DevTools profiler looks wrong: render counts are flat, commit durations are stable. The problem is not that React is rendering too much. The problem is that React is holding onto DOM that no longer exists on the page.

This is the class of leak that heap snapshot diffing is built to find. It is also the class of leak that most teams never look for, because the symptom (slow interactions over time) looks like a rendering problem and the cause (retained detached nodes) lives in the memory panel. This article covers how to find those nodes, how to read the retaining tree to identify the JavaScript reference keeping them alive, and which React 19.x patterns produce them.

What a detached node actually is

Chrome’s own documentation is precise about the definition: a DOM node can only be garbage collected when there are no references to it from either the page’s DOM tree or JavaScript code. A node is “detached” when it has been removed from the DOM tree but some JavaScript still references it. Detached DOM nodes are described by Chrome as a common cause of memory leaks (Fix memory problems).

That definition matters because it separates two things people conflate:

• A detached DOM node is a real DOM element that was removed from the document but is still reachable from JavaScript. It shows up in a heap snapshot under a Detached class filter, and it carries the full weight of the element plus its subtree.
• A leaked JavaScript object is any object that is still reachable when it should not be. It may or may not wrap a DOM node. A stale closure that captures a large array is a leaked object with no DOM involvement at all.

Both show up in the same heap snapshot, but they are found differently. Detached nodes are found by filtering the class list for Detached. Leaked objects are found by comparing two snapshots and looking at what grew. The Chrome Memory panel exposes both: the Heap snapshot profile type shows memory distribution among JavaScript objects and related DOM nodes, and the Detached elements profile type shows objects retained by a JavaScript reference (Memory panel overview).

The wrong approach: chasing render counts

When a page gets sluggish over time, the reflex is to open React DevTools, find the component that re-renders most, and wrap it in memo. This fails at scale for a specific reason: a detached node leak does not increase render counts. It increases the cost of every render that touches the surrounding tree, because the browser’s garbage collector has more live objects to trace, and because the retained subtree keeps its event listeners registered.

Chrome’s documentation is explicit about the user-visible consequence: during garbage collection, all script execution is paused. If the browser is collecting a lot, script execution gets paused a lot (Fix memory problems). That pause is what shows up as INP regression. You will not see it in a render profile, because it is not a render.

The second wrong approach is to assume that unmounting a component frees its DOM. It does not, if anything outside React still holds a reference. React removes the node from the tree; the browser frees it only when the last JavaScript reference goes away.

The procedure: snapshot diffing with a forced GC

The workflow below assumes Chrome DevTools. The Memory panel is opened via the Command menu (Command/Ctrl + Shift + P, type memory, select Show Memory) or via More tools > Memory.

1. Establish a baseline. Load the page, perform the interaction you suspect leaks (open and close a modal, navigate between routes, toggle a panel), then return to the starting state. Take a heap snapshot. Before taking it, click the collect garbage (mop) button so the snapshot reflects reachable memory, not pending garbage.
2. Repeat the interaction. Run the same open/close or navigate/return cycle several more times. Ten cycles is a reasonable starting point; the goal is to make the leak large enough to see above noise.
3. Force GC and take a second snapshot. Same collect-garbage step. If the interaction is clean, the second snapshot should be roughly the same size as the first.
4. Switch the view to Comparison. In the snapshot list, select the second snapshot and choose Comparison from the dropdown above the class list. The # Delta column now shows what grew between the two snapshots.
5. Filter for Detached. Type Detached into the Class filter. Any detached node that appears with a positive delta is a node that was created during your interaction cycles and never released.
6. Open the retaining tree. Select a detached node. The lower panel shows the retaining tree: the chain of references from a GC root down to this node. Read it bottom-up. The first non-internal frame is your suspect.

The retaining tree is the part people skip, and it is the only part that tells you what to fix. A detached node retained by a Window scope means a global or module-level variable. A detached node retained by a closure means a function that captured it. A detached node retained by a subscription callback means an unsubscribe that never ran.

Pattern 1: state that outlives the component

The most common retaining path in a React 19.x app is a state setter captured in an async callback that resolves after unmount. The classic shape:

useEffect(() => {
  fetchBio(person).then(result => {
    setBio(result); // runs even if the component is gone
  });
}, [person]);

React’s own documentation addresses this directly. The recommended pattern uses an ignore flag initialized to false and set to true during cleanup, so the resolved promise does not call setBio after the effect has been torn down (useEffect reference). The documentation frames this as protection against race conditions, where network responses arrive in a different order than they were sent. It also prevents the post-unmount state update.

Why this matters for memory: a setState call on an unmounted component does not throw in React 19, and it does not necessarily retain the DOM by itself. The retention happens when the resolved value is a large object graph, or when the callback closes over a ref that points at a DOM node. The ignore flag stops the write, which lets the closure and everything it captured become collectable.

For fetch specifically, AbortController is the stronger tool. The AbortController interface represents a controller object that allows you to abort one or more Web requests as and when desired, and abort() is able to abort fetch requests, consumption of any response bodies, and streams (MDN: AbortController). Aborting the request releases the response body and any listeners attached to the signal, rather than waiting for the promise to settle and then discarding the result.

useEffect(() => {
  const controller = new AbortController();
  fetch(`/api/bio/${person}`, { signal: controller.signal })
    .then(r => r.json())
    .then(setBio)
    .catch(err => { if (err.name !== 'AbortError') throw err; });
  return () => controller.abort();
}, [person]);

The ignore flag and AbortController are not interchangeable. The flag prevents a state write; the controller cancels the network work and frees the response. Use both when the response is large.

Pattern 2: subscriptions that never unsubscribe

React’s useEffect documentation lists the external systems that require cleanup explicitly: a timer managed with setInterval() and clearInterval(), an event subscription using window.addEventListener() and window.removeEventListener(), and a third-party animation library with an API like animation.start() and animation.reset(). The rule stated in the docs is that the cleanup function should stop or undo whatever the setup function was doing, and that the user should not be able to distinguish between setup running once (production) and setup → cleanup → setup (development) (useEffect reference).

When a subscription is not torn down, the callback stays registered on the external system. If that callback closes over a DOM node (a ref, a container element, a chart canvas), the node is retained. In the heap snapshot, the retaining tree will show the path through the subscription’s callback list, not through React.

The failure mode is subtle in development because React 19 runs an extra setup+cleanup cycle under Strict Mode. If your cleanup is incomplete, the extra cycle may mask or expose the problem depending on what the external system does with duplicate subscriptions. The documentation is direct about this: the extra cycle is a stress test that ensures your cleanup logic mirrors your setup logic, and if it causes a problem, implement the cleanup function.

Pattern 3: useSyncExternalStore with a store that holds DOM

useSyncExternalStore is the correct hook for reading from an external store in a way that is safe for concurrent rendering and server rendering. Its contract is specific: the subscribe function takes a single callback and returns a function that cleans up the subscription, and the getSnapshot function returns a snapshot of the data the component needs (useSyncExternalStore reference).

Two documented behaviors create retention risk in large apps:

Resubscription on every render. The React docs state that if a different subscribe function is passed during a re-render, React will re-subscribe to the store using the newly passed function. The troubleshooting section calls out the exact anti-pattern: a subscribe defined inside the component body is a different function on every render, so React resubscribes every time. The fix is to declare subscribe outside the component, or wrap it in useCallback so it only changes when its arguments change. If your store’s subscribe implementation adds a listener and the unsubscribe is not called before the next subscribe, you accumulate listeners, and each listener may hold a reference to the component’s DOM.

Uncached snapshots. The docs warn that getSnapshot must return the same value while the store has not changed, and that returning a new object every call produces the error “The result of getSnapshot should be cached.” Beyond the infinite-loop symptom, an uncached snapshot means React re-renders on every store notification, which increases the window during which closures and refs are live.

For server-rendered apps, the third argument getServerSnapshot is required if the component renders on the server. The docs note that the server snapshot must be the same between client and server, and is usually serialized and passed from the server to the client. A store that holds DOM references cannot be serialized, which is a signal that the store is doing too much: keep DOM references in refs and keep the external store to serializable data.

Pattern 4: stale closures in long-lived callbacks

A stale closure is a function that captured a value from an earlier render and is still being invoked. It retains everything in its scope, including any DOM node it touched. The retaining tree in a heap snapshot will show the closure as the retaining edge, and the closure’s scope will show the captured variables.

The React docs describe the mechanism that produces stale closures in effects: if some dependencies are objects or functions defined inside the component, there is a risk they cause the effect to re-run more often than needed, and the fix is to remove unnecessary object and function dependencies or extract non-reactive logic outside the effect. The inverse problem, a dependency list that is too short, produces a closure that captures a value from a render that no longer exists.

In a heap snapshot, a stale closure retaining a detached node looks like this: the detached node’s retaining tree passes through a function object, and that function’s scope contains a variable whose value is the node. The fix is not to add the missing dependency blindly (that can cause the effect to re-run on every render and create a different leak). The fix is to restructure so the callback does not need to capture the node: pass the node as an argument, read it from a ref at call time, or move the callback outside the component.

Server-side: catching heap growth across renders

Detached node leaks are a client problem, but the same class of retention shows up on the server as heap growth across repeated renders of the same component tree. Node exposes process.memoryUsage() for this. The method reports memory usage in bytes, and the Node documentation includes a note on interpreting the values (Node.js process documentation).

A practical check for a server-rendered React 19.x app: render the same route N times in a loop, call process.memoryUsage().heapUsed after each render, and force a GC between samples if you run with --expose-gc. A flat line after GC means the render is clean. A line that climbs and does not return to baseline means something in the render path is retaining. Common causes are module-level caches keyed by request, memoization maps that never evict, and closures stored on a long-lived object.

This is a coarse signal. It tells you a leak exists, not where. For the location, use the Node inspector’s heap profiler with the same snapshot-diffing approach described above.

Reading the retaining tree without guessing

The retaining tree is a path, not a list. Read it from the detached node upward. The frames you will see most often, and what they mean:

• Window / global — a module-level variable or a property set on window. Look for caches, singletons, and anything assigned outside a component.
• Closure — a function that captured the node. Expand the closure to see which variable holds it.
• EventListener / EventTarget — a listener that was added and never removed. The listener’s callback is the retaining edge.
• Promise / then — an in-flight or resolved promise whose continuation captured the node. This is the fetch-without-abort pattern.
• Map / Set — a collection that was never cleared. Look for subscription registries and memo caches.

If the retaining tree passes through React internals (fiber nodes, hook state), the reference is coming from React state or a ref that was not cleared. That is a different fix: clear the ref in cleanup, or move the value out of state.

What to measure before and after

A leak fix without a measurement is a guess. The measurements that matter for this class of bug:

• Detached node count in the Comparison view after N interaction cycles. Before: grows linearly with cycles. After: flat.
• JS heap live size in the Chrome Task Manager after forced GC. Before: staircase. After: returns to baseline.
• INP on the interaction that triggers the leak, measured after the page has been open long enough for GC pressure to build. This is the user-visible number, and it is the one that justifies the work.
• Long tasks in the Performance panel during the interaction. GC pauses show up here as tasks with no script attribution.

Take all four before the fix and after. If the detached node count drops but INP does not move, the leak was not on the critical path and the fix is still correct but not urgent. If INP moves and the node count does not, you fixed something else.

FAQ

Does React 19 automatically clean up effects on unmount?
React runs the cleanup function returned from useEffect after the component is removed from the DOM. It does not clean up anything you did not return a cleanup for. Timers, subscriptions, and in-flight requests need explicit teardown.

Why does the leak only show up in production?
Development builds run extra setup+cleanup cycles under Strict Mode, which can surface or mask incomplete cleanup. Production builds also run longer between reloads, which is when accumulation becomes visible. The leak exists in both; the timeline differs.

Is a detached node always a leak?
No. A node can be detached and still referenced intentionally, for example a cached offscreen element. It is a leak when the reference outlives its purpose. The heap snapshot shows the reference; only you can judge whether it should exist.

Can I find these leaks without a heap snapshot?
The Detached elements profile in the Memory panel shows detached elements retained by JavaScript reference and reports the exact HTML nodes and node count. It is faster than a full snapshot diff for confirming the problem exists, but the retaining tree in a heap snapshot is what identifies the cause.

Does useSyncExternalStore leak if I forget to unsubscribe?
React calls the unsubscribe function returned by subscribe when the component unmounts or when the subscribe function identity changes. If your store’s subscribe adds a listener and your unsubscribe does not remove it, the listener accumulates. The React docs specifically warn about passing a new subscribe function on every render, which causes resubscription on every render.