Prefetching downloads a route before the user clicks. Next.js prefetches visible links in production, but the benefit depends on the route size, the connection and whether the user is likely to go there.
Key takeaways
- Target: Make likely navigations fast without wasting bandwidth on unlikely ones.
- Measure field data before choosing a fix.
- Change one bottleneck at a time and re-measure on a mid-range phone.
- A fast lab score is not a substitute for real-user data.
What Prefetching measures
Use the network panel to see which route chunks load on hover or in the viewport. Compare navigation time with prefetching on and off, especially on mobile data.
The fixes that usually move the number
- Let Next.js prefetch visible, likely links; avoid disabling it globally.
- Disable prefetch on heavy, authenticated or rarely used routes.
- Use hover prefetch for desktop navigation where appropriate.
- Keep route bundles small so prefetching does not compete with the current page.
- Measure on a throttled connection, not just localhost.
Symptom, cause and fix
| Symptom | Likely cause | What to do |
|---|---|---|
| Navigation still slow after click | Route bundle is large or data is fetched on the client | Reduce the route bundle and fetch on the server |
| Too much data on mobile | Every visible link prefetched | Disable prefetch on heavy or unlikely routes |
| Prefetch of a private page | Auth-only route cached | Disable prefetch and protect the route |
| Double fetching | Prefetch and client fetch duplicate the request | Use the same server data and cache key |
How to measure it properly
- Pick a key navigation. Home to pricing, product to checkout or blog to post.
- Watch the network. See when the route chunk and data requests start.
- Throttle the connection. Test on a slow 4G profile with a mid-range CPU.
- Compare click-to-paint. Measure with prefetch enabled and disabled.
- Check the cost. Confirm prefetching does not delay the current page's LCP or INP.
A practical example
<Link href="/pricing" prefetch={false}>
Pricing
</Link>Common mistakes
- Turning off prefetch everywhere because one heavy route caused a problem.
- Prefetching authenticated dashboards that should not be cached.
- Expecting prefetch to fix a slow route bundle.
- Testing only on a fast local network.
A 30-day improvement plan
- Week 1. Collect field data and pick the worst route. Write down the baseline.
- Week 2. Fix the largest bottleneck and deploy behind a normal release.
- Week 3. Test on a mid-range phone and a throttled connection; fix regressions.
- Week 4. Compare field data, document the change and add a monitor or budget.
Field data vs lab data
| Source | What it tells you | How to use it |
|---|---|---|
| Field data | What real users experienced | The source of truth for the metric |
| Lab test | A reproducible diagnosis | Find the cause and test a fix |
| Synthetic monitoring | Availability and regressions over time | Alert on a budget breach |
| RUM segmentation | Device, country and route differences | Target the worst segment |
| Server timing | Database, cache and render time | Separate backend from frontend |
Set a performance budget
| Budget | Example starting point | Why |
|---|---|---|
| LCP | 2.5s or less at p75 | The main content must appear quickly |
| INP | 200ms or less at p75 | Interactions must feel responsive |
| CLS | 0.1 or less at p75 | Layout movement erodes trust |
| JavaScript | A route-level KB budget | Prevents bundle creep |
| Images | Responsive sizes and modern formats | The largest common payload |
| Third-party scripts | A named owner and a cap | Uncontrolled tags are a common regression |
Third-party script policy
- Every script needs an owner, a purpose and a review date.
- Load analytics and marketing tags after consent and after the main content.
- Prefer server-side events where they reduce client JavaScript.
- Test the checkout and sign-up with the full tag set enabled.
- Remove tags that no longer answer a business question.
Frequently asked questions
The target is Make likely navigations fast without wasting bandwidth on unlikely ones. A single fast test is not enough; use the 75th percentile of real page views and segment by mobile and desktop.
No. Start with the routes that matter to revenue or support: checkout, pricing, sign-up, the main product page and the most-read blog template. A fast homepage with a slow checkout is not a fast site.
It depends on traffic. Low-traffic sites can take weeks to accumulate enough data. Use lab tools for immediate feedback, but keep the field metric as the source of truth.
Often yes. Image dimensions, priority, bundle splits, caching and third-party scripts usually deliver more than a visual refresh. Redesign only after the measurement shows the layout itself is the bottleneck.
Sources and further reading
- Next.js server and client components (nextjs.org)
- Next.js data fetching (nextjs.org)
- Web Vitals (web.dev)
Related reading
Need a performance audit?
Send the URL and the metric that matters. I will identify the bottleneck, the likely fix and the cheapest way to prove it worked.
How to cite this guide: Nur Hossain Repon, “Prefetching Optimization Guide for Next.js and React Apps”, Nhrepon Portfolio, reviewed October 2026, https://nhrepon.com/posts/prefetching-optimization-guide-for-next-js-and-react-apps.
Comments
No comments yet.