How to Reduce Edge Requests in Next.js (v15.2.1 App Router)

[hyjoong]

Summary

I deployed a Next.js project (v15.2.1, App Router) to Vercel. The site gets ~1,500–2,000 daily visitors, but Edge Requests are averaging around 40K/day. From my understanding, each static asset request (JS chunks, CSS, images) also counts as an Edge Request, which might explain the high number.

I’ve minimized static assets (especially large images) as much as possible, but the Edge Requests count is still high. Is there any way to reduce this number, or is this behavior expected?

Static assets and pages are served with default Next.js caching settings.

Example 12-hour Edge Requests breakdown:

Are there recommended optimizations to reduce Edge Requests count?

Additional information

No response

Example

No response

[grilomatheus]

You’re right that Edge Requests will be much higher than users — each file (HTML, JS chunks, CSS, images, API/data, favicon, prefetches) counts as an edge request. ~40k/day for ~2k visits (~20 req/visit) is not unusual, but you can often trim it.

Things that usually move the needle:

1. Disable automatic prefetch where you don’t need it
   Next’s <Link> prefetches route assets on hover/in-viewport and can multiply requests.

// Per link
<Link href="/heavy-route" prefetch={false}>Heavy route</Link>

If you have many links (menus, footers, index pages), this alone can drop a lot of edge hits.

2. Keep routes static (or cacheable) when possible
   If a route reads cookies(), headers(), or sets dynamic = "force-dynamic", it bypasses static/edge caching.

• Prefer export const dynamic = "force-static" or set a sensible revalidate:

export const revalidate = 60; // cache the HTML/data at the edge for 60s

• In fetch(), avoid cache: "no-store" unless truly needed. Use force-cache/revalidate.

3. Check browser caching (to avoid repeat edge hits)
   Your chunks show ~100% cache hit (good), but I notice favicon.ico often has low cache ratio in many setups.

• Put public/favicon.ico and send a far-future header:

// next.config.js
export default {
  headers: async () => ([
    { source: '/favicon.ico', headers: [{ key:'Cache-Control', value:'public, max-age=31536000, immutable' }] }
  ])
}

• Same idea for big, never-changing assets in /public.

4. Reduce number of assets per page

• Split “rarely-used” code with next/dynamic so it’s not loaded on first view.
• Audit third-party scripts and CSS.
• Use next/font (self-hosted) so fonts are cached efficiently.

5. Images

• Use <Image /> with proper sizes and let Vercel cache them.
• If using many icons/images, consider sprite sheets or inlining tiny SVGs to cut requests.

6. PWA layer (optional but effective)
   A lightweight service worker that caches hashed /_next/static/* and /public/* can eliminate repeat edge requests for returning users.

Is this expected?
Yes: with modern apps, 15–40 requests per visit is common. What matters is cache hit ratio and total transfer. If most entries show high cache %, you’re in a good place; the raw “Edge Requests” number will still look big.

If you want, share a public route and I can point at the biggest request multipliers (usually link prefetch + dynamic routes + un-cached images).

[melodyxpot]

So, is prefetch={false} needed for unusual pages redirects?