) }

Behind the scenes, Next.js wraps your page.tsx in a <Suspense> boundary automatically. The prefetched skeleton becomes the fallback — it shows immediately on click — and gets swapped for real content once the server responds.

The improvements are measurable across three Core Web Vitals:

• TTFB — unchanged (server still renders), but perceived TTFB drops to zero
• FCP — skeleton renders immediately instead of blank screen
• TTI — shared layouts stay interactive during the transition

💡 Tip: Design your skeleton to match the real layout dimensions. Layout shift during the swap tanks your CLS score. Match heights as closely as possible.

Option 2: Use generateStaticParams to Prerender the Route

If the route’s content is known at build time — blog posts, product pages, documentation — you should be statically prerendering it, not relying on dynamic rendering at all.

The fix is generateStaticParams. Without it, even a route that could be static will fall back to dynamic rendering at request time.

// app/blog/[slug]/page.tsx // Tell Next.js which slugs to prerender at build time export async function generateStaticParams() { const posts = await fetch(‘https://your-api.com/posts’).then(res => res.json()) return posts.map((post: { slug: string }) => ({ slug: post.slug, })) } export default async function Page({ params, }: { params: Promise<{ slug: string }> }) { const { slug } = await params // fetch and render post content }

Once this is in place, /blog/[slug] becomes a static route. Full prefetching kicks in. Navigation becomes instant — no server round-trip, no loading state needed.

Honestly, generateStaticParams should be the first thing mentioned in every dynamic route tutorial. It almost never is. If your content doesn’t change per-request (most blog posts, most product pages), this is the correct solution, not loading.tsx.

Use both together for the best outcome: generateStaticParams for known slugs, loading.tsx as a fallback for slugs generated after build (ISR, on-demand revalidation).

---

When to Disable Prefetching (and How to Do It Safely)

Prefetching costs bandwidth and server compute. For most routes it’s worth it. But there are cases where you should opt out.

Infinite scroll tables. If you’re rendering 200 rows each containing a <Link>, Next.js will attempt to prefetch 200 routes when the table mounts. That’s almost certainly not what you want.

// Disable prefetching for link-heavy lists {item.name}

The tradeoff is real: static routes will cold-load on click, dynamic routes need a full server render. You’re trading perceived performance for resource usage.

A middle path: prefetch only on hover. This limits prefetching to routes the user signals intent for, rather than everything in the viewport.

// app/ui/hover-prefetch-link.tsx ‘use client’ import Link from ‘next/link’ import { useState } from ‘react’ function HoverPrefetchLink({ href, children, }: { href: string children: React.ReactNode }) { const [active, setActive] = useState(false) return ( setActive(true)} > {children} ) }

This pattern works well for data tables, sidebars with many items, and search results. It’s worth noting I haven’t benchmarked this against every viewport/scroll combination — if your list is extremely dynamic, validate the behavior manually.

---

Measuring the Difference

Don’t ship prefetching changes without measuring them. Two places to check:

Chrome DevTools Network tab — Filter by Fetch/XHR and look for RSC payload requests (they contain ?_rsc= in the URL). You should see these firing before you click, as links enter the viewport. If you only see them after clicking, prefetching isn’t running.

Web Vitals JS library or GA4 custom events — For production monitoring, capture INP (Interaction to Next Paint) on <Link> clicks. If your dynamic routes are cold-loading, INP will be high. After adding loading.tsx, INP drops because the transition starts instantly.

// app/layout.tsx — track navigation INP via GA4 ‘use client’ import { onINP } from ‘web-vitals’ import { useEffect } from ‘react’ export function WebVitalsTracker() { useEffect(() => { onINP(({ value, id }) => { // Push to GTM dataLayer or GA4 directly window.dataLayer?.push({ event: ‘web_vitals’, metric_name: ‘INP’, metric_value: Math.round(value), metric_id: id, }) }) }, []) return null }

Wire this up before and after your prefetching changes. The before/after delta is the clearest way to justify the work to stakeholders.

---

Summary

Next.js prefetching works automatically — but only for static routes. Dynamic routes, the ones powering most real content, get skipped unless you opt in explicitly.

The fix is usually one of these, in order of impact:

1. generateStaticParams — if the route’s slugs are known at build time, prerender them. Full prefetch kicks in automatically.
2. loading.tsx — unlocks partial prefetching for dynamic routes. Skeleton shows instantly on click.
3. HoverPrefetchLink — for link-heavy lists where viewport prefetching is wasteful.
4. Bundle size reduction — if hydration is slow, prefetching starts late. Audit with @next/bundle-analyzer.

The key mental model shift: <Link> isn’t a prefetch guarantee. It’s a prefetch request that Next.js may honor fully, partially, or not at all depending on route type and hydration state.

---

FAQ

Why does prefetching work in development but not production?

The opposite is usually true — prefetching is more aggressive in production. In development, Next.js uses dynamic rendering for most routes to support hot reload. If navigation feels fast in dev but slow in production, the issue is likely missing loading.tsx or generateStaticParams for dynamic routes.

Does prefetching work with dynamic search params (e.g., /search?q=...)?

Not automatically. Prefetching is path-based. Query params that change per-request won’t be prefetched. The useLinkStatus hook is the right tool for showing feedback during these navigations.

What’s the difference between prefetch={false} and prefetch={null}?

null is the default behavior — prefetch based on route type. false disables prefetching entirely. There’s no true option that forces prefetching of dynamic routes.

Will generateStaticParams cause stale content?

Yes, if your content changes after build. Use revalidate (ISR) to control how often static pages regenerate. For content that changes frequently, stick with dynamic rendering + loading.tsx.

Does prefetching happen on mobile?

Viewport-based prefetching works on mobile too. Hover-based prefetching doesn’t (no hover events). On slow mobile networks, prefetches may not complete before a user clicks — that’s where useLinkStatus becomes important for showing a manual loading indicator.

---