Linking and Navigating

In Next.js, routes are rendered on the server by default. This often means the client has to wait for a server response before a new route can be shown. Next.js comes with built-in prefetching, streaming, and client-side transitions ensuring navigation stays fast and responsive.
This guide explains how navigation works in Next.js and how you can optimize it for dynamic routes and slow networks.
To understand how navigation works in Next.js, it helps to be familiar with the following concepts:
In Next.js, Layouts and Pages are React Server Components by default. On initial and subsequent navigations, the Server Component Payload is generated on the server before being sent to the client.
There are two types of server rendering, based on when it happens:
The trade-off of server rendering is that the client must wait for the server to respond before the new route can be shown. Next.js addresses this delay by prefetching routes the user is likely to visit and performing client-side transitions.
HTML is also generated for the initial visit.
Prefetching is the process of loading a route in the background before the user navigates to it. This makes navigation between routes in your application feel instant, because by the time a user clicks on a link, the data to render the next route is already available client side.
Next.js automatically prefetches routes linked with the <Link> component when they enter the user's viewport.
How much of the route is prefetched depends on whether it's static or dynamic:
By skipping or partially prefetching dynamic routes, Next.js avoids unnecessary work on the server for routes the users may never visit. However, waiting for a server response before navigation can give the users the impression that the app is not responding.
See the Prefetching guide for the full behavior, including how to control prefetching per link and how it changes when you adopt Partial Prefetching. To include URL-dependent content in a link's prefetch, see Optimizing prefetching.
To improve the navigation experience to dynamic routes, you can use streaming.
Streaming allows the server to send parts of a dynamic route to the client as soon as they're ready, rather than waiting for the entire route to be rendered. This means users see something sooner, even if parts of the page are still loading. See the Streaming guide for a deep dive into how streaming works in Next.js.
For dynamic routes, it means they can be partially prefetched. That is, shared layouts and loading skeletons can be requested ahead of time.
To use streaming, create a loading.tsx in your route folder:
Behind the scenes, Next.js will automatically wrap the page.tsx contents in a <Suspense> boundary. The prefetched fallback UI will be shown while the route is loading, and swapped for the actual content once ready.
You can also use <Suspense> to create loading UI for nested components.
Benefits of loading.tsx:
To further improve the navigation experience, Next.js performs a client-side transition with the <Link> component.
Traditionally, navigation to a server-rendered page triggers a full page load. This clears state, resets scroll position, and blocks interactivity.
Next.js avoids this with client-side transitions using the <Link> component. Instead of reloading the page, it updates the content dynamically by:
Client-side transitions make server-rendered apps feel like client-rendered apps. And when paired with prefetching and streaming, they enable fast transitions, even for dynamic routes.
Next.js also handles scrolling to the top of the page during client-side transitions. If content scrolls behind a sticky or fixed header after navigation, you can fix this with CSS scroll-padding-top.
These Next.js optimizations make navigation fast and responsive. However, under certain conditions, transitions can still feel slow. Here are some common causes and how to improve the user experience:
When navigating to a dynamic route, the client must wait for the server response before showing the result. This can give the users the impression that the app is not responding.
We recommend adding loading.tsx to dynamic routes to enable partial prefetching, trigger immediate navigation, and display a loading UI while the route renders.
In development mode, you can use the Next.js Devtools to identify if the route is static or dynamic. See devIndicators for more information.
If a dynamic segment could be prerendered but isn't because it's missing generateStaticParams, the route will fallback to dynamic rendering at request time.
Ensure the route is statically generated at build time by adding generateStaticParams:
On slow or unstable networks, prefetching may not finish before the user clicks a link. This can affect both static and dynamic routes. In these cases, the loading.js fallback may not appear immediately because it hasn't been prefetched yet.
To improve perceived performance, you can use the useLinkStatus hook to show immediate feedback while the transition is in progress.
You can "debounce" the hint by adding an initial animation delay (e.g. 100ms) and starting as invisible (e.g. opacity: 0). This means the loading indicator will only be shown if the navigation takes longer than the specified delay. See the useLinkStatus reference for a CSS example.
An experimental useOffline hook can keep prefetched routes navigable during connectivity drops. See the offline support guide.
You can use other visual feedback patterns like a progress bar. View an example here.
You can opt out of prefetching by setting the prefetch prop to false on the <Link> component. This is useful to avoid unnecessary usage of resources when rendering large lists of links (e.g. an infinite scroll table).
However, disabling prefetching comes with trade-offs:
To reduce resource usage without fully disabling prefetch, you can prefetch only on hover. This limits prefetching to routes the user is more likely to visit, rather than all links in the viewport.
<Link> is