Unexpected high serverless function usage on Vercel with Next.js App Router

[kawai-me]

Hi everyone 👋

I’m running a Next.js (App Router) project on Vercel and noticed that my Serverless Function usage is much higher than expected, even though most of my pages should be cached.

I’m trying to understand what might be causing this.

Setup

• Next.js App Router
• Deployed on Vercel
• Using fetch with revalidate
• No obvious API routes being hit frequently
• Traffic is moderate, but function invocations are surprisingly high

What confuses me

I assumed that after the first request, pages would be served from cache and wouldn’t keep invoking serverless functions.

But Vercel analytics show functions running far more often than expected.

Questions

• What patterns in App Router cause functions to run on every request?
• Does using cookies, headers, or dynamic data force SSR every time?
• How can I verify whether a route is truly cached vs dynamically rendered?
• What’s the best way to reduce unnecessary function executions?

If anyone has insights into this or debugging tips, I’d really appreciate the help.

Thanks!

[anurag-dwivedi-live]

Hi! This is a very common confusion with the App Router on Vercel.

What usually happens is that something in the route is silently forcing it to be dynamic, so Vercel can’t serve it from the cache and has to run the Serverless Function on every request.

The most common triggers are:

• Using cookies() or headers() anywhere in the tree
• Reading request-specific data
• fetch without proper caching config
• Setting cache: 'no-store'
• Using Server Actions in the same route
• Having export const dynamic = 'force-dynamic' (even indirectly)

Any of these make the route SSR on every hit.

How to verify

Check the response headers in the browser:

• If you see: x-vercel-cache: HIT → served from cache
• If you see: MISS or BYPASS → function executed

How to fix

Make sure your data fetching looks like this:

await fetch(url, {
  next: { revalidate: 60 },
});

Avoid using cookies() / headers() in pages that should be cached. If you need them, move that logic to a separate dynamic route or API route.

You can also explicitly force static behavior:

export const dynamic = 'force-static';

Once the route becomes truly static/ISR, you’ll see function usage drop and x-vercel-cache start returning HIT.

Hope this saves you some function invocations

[icyJoseph]

How is this even an answer?

What action were you able to take to reduce your function invokations?

[icyJoseph]

• What patterns in App Router cause functions to run on every request?

Without Cache Components on, pages are either, fully static, or fully dynamic. There isn't really a good in-between hybrid. A fully dynamic page gets to access latest data and such, but needs to be mindful of Suspense states to start pushing out UI to the browser as it renders to completion.

A fully static page serves from CDN, immediately, but might have stale data. To try and marry these two ideas, ISR was introduced, a static page that regenerates itself, at runtime, given certain parameters.

The key bit here is that fully dynamic page in the current model, is any page that access so-called dynamic data within its React tree.

Dynamic data in this model are things such as cookies, searchParams, headers, etc - these are only known when a request arrives, so they can't be statically prerendered. There's also fetch, and the part that's a bit confusing in the current model, not-in-cache-components, that you can make fetch explicitly cached, or mark it as data that may be stale for a revalidate time, and that changes how the page behaves.

• Does using cookies, headers, or dynamic data force SSR every time?

Yes. In Cache Components this nuanced and likely more close to what you'd expect.

• How can I verify whether a route is truly cached vs dynamically rendered?

The build output prints clearly which routes are fully static, dynamic, and such, each route gets an icon and the icon legend is printed at the bottom.

• What’s the best way to reduce unnecessary function executions?

Depends on your use case. If you want to show financial info by the second, you are likely going to need to more frequent server function execution. If you are showing the list of the first 150 pokemon, you can statically render that on a page and that and cut your runtime server function execution to zero.