How to Reduce Vercel Edge Requests: 6 Fixes and a 10-Minute Audit

Short answer: to reduce Vercel Edge Requests (Vercel now calls them CDN Requests), stop paying for requests no human asked for. In most AI-built Next.js apps that means four things: turn off automatic prefetching on long lists and footers, give Routing Middleware a matcher so it skips static files, stop polling and refetch-on-focus loops, and block junk bot traffic at the Vercel Firewall, because denied and challenged requests don't count toward CDN Requests. Then run the 10-minute request audit below to see which of these is actually driving your number. If the number is already hurting, our Vercel bill review walks through your usage page with you and finds the biggest lines first.

This guide is for founders who built with Lovable, Bolt, Cursor, Replit or v0, deployed to Vercel, and now see a usage chart that grows much faster than their real visitors.

Edge Requests and CDN Requests are the same number

If you're searching for "Vercel Edge Requests", you're in the right place, but the dashboard may not use that name anymore. Vercel's own course material says the metric used to be called Edge Requests and is now called CDN Requests, on the Usage page and in Observability. Same number, new name.

According to Vercel's CDN usage docs, CDN Requests count every request the CDN processes for your project: pages, React Server Component (RSC) payloads, static assets like JavaScript and images, and API calls. On the Hobby plan the first 1,000,000 a month are included; on Pro, CDN usage is either metered per unit with regional pricing or covered by a Flat Rate CDN tier. There's also a related line, CDN Request CPU Duration, which only charges for requests that take more than 10 ms of routing work.

The key idea: a request counts whether or not a person ever saw the result. A page view isn't one request. It's the page, plus every script, stylesheet, font and image, plus every background fetch the framework decides to make.

What we measured on our own Next.js site

Before giving advice, we checked our own site, blitzhash.com, which runs Next.js on Vercel. Here's what we found with nothing but curl on November 5, 2026:

• The homepage HTML is about 117 KB and contains 75 internal links pointing to 40 different pages, plus 10 script tags and 16 images.
• The response header vary: rsc, next-router-state-tree, next-router-prefetch, next-router-segment-prefetch confirms that the CDN treats prefetch requests as their own cached variants.
• When we sent the same headers a Next.js prefetch sends (RSC: 1 and Next-Router-Prefetch: 1) to three of those linked pages, each returned its own 200 response: 36,020 bytes for /check, 26,228 bytes for /self-check and 30,551 bytes for /care.
• Hashed JavaScript under /_next/static came back with cache-control: public,max-age=31536000,immutable, so returning visitors don't re-request it. The favicon came back with max-age=0, must-revalidate, so browsers check it again.
• Bot-style probes for /.env and /wp-login.php were answered quickly (404 and 410), but each one is still a request the CDN processed.

None of that is a bug. It's just how a modern app works. It shows where the multipliers hide, though: every link on a page is a possible extra request, and every scanner that probes your domain adds requests no customer made.

The 10-minute request audit

Do this before you change any code, so you have a "before" number.

Step 1: Find the project and the day

Open your team's Usage page in the Vercel dashboard, open the CDN Requests chart, and filter by project. Note the daily count for a normal day. If one day spikes, write down the date; spikes usually mean bots, while a steady climb usually means your own code.

Step 2: Count requests per page view

Open your live site in a private browser window, open DevTools (F12), go to the Network tab, tick "Disable cache", and load your homepage. Then:

1. Note the request count shown at the bottom of the Network tab. 2. Scroll slowly to the bottom of the page without clicking anything. 3. Note the new count. Every request that appeared while you scrolled is something the page fetched on its own. 4. Type rsc into the Network filter box. Requests with _rsc= in the URL are Next.js route payloads, and on a static page most of them are prefetches.

Write down three numbers: requests on load, requests after scrolling, and RSC requests. The gap between the first two is your prefetch and lazy-loading cost.

Step 3: Leave the tab open for two minutes

Don't touch anything. Switch to another tab and back once. If new requests keep appearing, your app is polling or refetching on focus.

Step 4: Look at the paths, not just the count

In Observability, open the CDN Requests view and sort by path. You're looking for three patterns: _rsc paths on pages people rarely visit, one API route with far more hits than page views, and paths your app doesn't even have (/wp-admin, /.env, /xmlrpc.php). Each pattern maps to one of the fixes below.

Six ways to reduce Vercel Edge Requests

1. Turn off prefetching where people rarely click

Next.js prefetches automatically in production. Its docs explain that as each ` enters the viewport, Next.js prefetches the route behind it. Static routes are prefetched in full; dynamic routes are skipped unless they have a loading.js` file. On a blog index, product grid, or a footer with 30 links, that adds up fast.

Turn it off on high-volume lists and footers:

  {post.title}

Navigation still works. The page just loads when someone clicks instead of before. Keep prefetching on your main navigation, because almost everyone clicks it and instant navigation is a real benefit.

If you want a middle ground, Next.js documents a hover-to-prefetch pattern: start with prefetch={false} and switch to the default once the mouse enters the link. That keeps the speed for links people actually point at.

AI-builder prompt you can paste: "In this Next.js app, add prefetch={false} to every Link inside lists that map over data (blog posts, products, table rows) and inside the footer. Leave the header navigation links unchanged. Don't change any URLs."

2. Give Routing Middleware a matcher

AI tools love to add a middleware.ts (newer projects may call it proxy.ts) for auth redirects. Vercel's Routing Middleware docs are blunt: without a matcher, middleware runs on every request, including static files, which adds latency and cost to each one. Its CDN docs add that middleware can cause Fast Origin Transfer to be charged twice for a single function request.

Limit it to the paths that need it:

export const config = {
  matcher: ['/dashboard/:path*', '/account/:path*'],
};

Or exclude static assets if it really must run broadly:

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
};

Vercel also says that if a redirect, rewrite or header doesn't need custom logic, put it in vercel.json or next.config.js instead, because static rules run on the CDN without invoking your code.

3. Stop polling and refetch-on-focus loops

Vercel's docs name excessive polling and data-fetching libraries that reload data when the window regains focus (they mention SWR and React Query) as one of the biggest sources of extra CDN Requests. A dashboard that refetches five widgets every 10 seconds turns one open tab into 1,800 requests an hour.

What to change:

• Raise polling intervals to what the data actually needs. Most "live" numbers are fine at 60 seconds.
• Pause polling when the tab is hidden.
• In SWR set revalidateOnFocus: false, and in React Query set refetchOnWindowFocus: false, on queries that don't need it.
• For truly live data, use a realtime connection instead of polling.

4. Stop re-mounting images and lists

Vercel's docs also call out frequent re-mounting: when a large list of images is unmounted and mounted again (for example, every time a filter changes), the browser can request the same files again. In DevTools you'll see repeated 304 responses for the same image paths. Each 304 is cheap, but it's still a request. Keep stable key props on list items and avoid wrapping whole grids in components that reset on every state change.

5. Block junk bots at the Vercel Firewall

This is the fix most founders miss. Vercel's WAF pricing docs say that traffic denied, challenged or rate-limited by the WAF does not incur CDN Requests or Fast Data Transfer; only requests that pass a challenge and continue to your app count. The same applies to DDoS mitigation, Attack Mode and IP blocking. Custom rules and IP blocking are free on all plans.

Practical first rules:

• Deny requests to paths your app doesn't have: /wp-admin, /wp-login.php, /xmlrpc.php, /.env, /.git.
• Challenge or rate-limit your signup, login and AI endpoints.
• If one country or network keeps hammering you with no real users there, challenge it rather than deny it.

Put new rules in log mode first if you're unsure, then switch to deny once you've confirmed real users aren't caught. For signup forms specifically, pair this with the server-side checks in our Cloudflare Turnstile signup tests.

6. Cache what doesn't change

Requests that hit the cache still count as CDN Requests, but caching keeps browsers from coming back and keeps requests from turning into function invocations. Make marketing and blog pages static or use a sensible revalidate, give long-lived files in /public (logos, fonts, PDFs) a long Cache-Control header, and use next/font so fonts come from your own domain with good caching. If you were using the old Data Cache, read our note on Vercel's move from Data Cache to Runtime Cache first.

How to know it worked

Wait two or three normal days after deploying, then compare:

• Requests per visit. Divide daily CDN Requests by daily visitors (from your analytics). This should fall, even if total traffic grows.
• RSC request count. Repeat Step 2 of the audit. RSC requests after scrolling should drop sharply on pages where you disabled prefetching.
• Top paths. Bot paths like /wp-login.php should disappear from the CDN Requests view once the firewall denies them, and the Firewall tab should show them as blocked.

If the total barely moves, CDN Requests probably aren't your biggest cost. Our guide to the Vercel usage lines that grow fastest covers the others, including function compute and image optimization, plus how to set a spend cap.

Printable checklist: reduce Vercel Edge Requests

Copy this into your notes and tick each line:

• ☐ Wrote down today's CDN Requests count for the project (before number)
• ☐ Counted requests on load, after scrolling, and RSC requests in DevTools
• ☐ Left a tab open for two minutes and checked for polling
• ☐ Sorted Observability by path and noted the top 10
• ☐ Added prefetch={false} to list, grid and footer links
• ☐ Kept prefetching on the main navigation
• ☐ Added a matcher to middleware (or moved simple redirects to config)
• ☐ Raised polling intervals and turned off refetch-on-focus where not needed
• ☐ Checked for repeated 304 image requests from re-mounting
• ☐ Added firewall rules denying /wp-admin, /wp-login.php, /xmlrpc.php, /.env, /.git
• ☐ Added rate limiting or a challenge to signup, login and AI endpoints
• ☐ Gave long-lived /public files a long Cache-Control header
• ☐ Compared requests per visit after 2 to 3 days (after number)

FAQ

Are Vercel Edge Requests and CDN Requests the same thing?

Yes. Vercel renamed Edge Requests to CDN Requests. Older blog posts, forum threads and screenshots use the old name, but it's the same metric on the same Usage page.

Does prefetch={false} make my site slower?

Only a little, and only for that link. The page's code downloads when someone clicks instead of in advance. For links people rarely click, that's a good trade. Keep prefetching on the handful of links almost everyone uses.

Do blocked bot requests count against my CDN Requests?

According to Vercel's WAF docs, no. Requests denied, challenged or rate-limited by the Vercel Firewall don't incur CDN Requests or Fast Data Transfer. Requests that pass a challenge and reach your app count as normal.

How many requests per page view is normal?

There isn't one right number, because it depends on how many scripts, images and links a page has. What matters is the trend: requests per visit should stay flat or fall as you grow. If it climbs while your pages stay the same, look for prefetching, polling or bots.

Want a second pair of eyes?

If your Vercel usage keeps climbing and you're not sure which line is to blame, book a free technical assessment through our Vercel bill review. We'll go through your usage and request paths with you and point out the fixes worth doing first. If you'd like to start on your own, the free self-check covers the launch basics in a few minutes.