--- title: How can I reduce my Vercel Functions usage on Vercel? description: Reduce Vercel Functions usage and cost under Fluid compute pricing with caching, rendering strategies, and function configuration. url: /kb/guide/how-can-i-reduce-my-serverless-execution-usage-on-vercel canonical_url: "https://vercel.com/kb/guide/how-can-i-reduce-my-serverless-execution-usage-on-vercel" last_updated: 2026-07-23 authors: Lee Robinson related: - /docs/concepts/limits/usage - /docs/limits/fair-use-guidelines - /docs/concepts/deployments/logs - /docs/functions - /docs/fluid-compute - /docs/project-configuration - /docs/edge-network/overview - /docs/concepts/edge-network/headers - /docs/functions/configuring-functions/region - /docs/functions/configuring-functions/memory - /docs/functions/configuring-functions/duration - /docs/functions/limitations - /docs/functions/runtimes - /docs/functions/usage-and-pricing/legacy-pricing install_vercel_plugin: npx plugins add vercel/vercel-plugin --- New Vercel projects run on Fluid compute by default, and Vercel bills that compute on Active CPU, Provisioned Memory, and Invocations. Time spent waiting on I/O does not count toward Active CPU, so functions that mostly wait on a database or an upstream API cost less than they did under earlier duration-based pricing. Even so, high traffic and inefficient patterns can drive up usage. This guide shows you where to check that usage and how to bring it down without changing what your application delivers. The [Usage dashboard](https://vercel.com/docs/concepts/limits/usage) is the most important page for tracking the usage of your projects, and it helps you confirm you stay within the [fair use guidelines](https://vercel.com/docs/limits/fair-use-guidelines) or your Enterprise agreement (email your Customer Success Manager (CSM) or Account Executive (AE) for further information). To monitor requests and errors, use the [Function Logs](https://vercel.com/docs/concepts/deployments/logs#function-logs) tab, which provides logging output for your [Vercel Functions](https://vercel.com/docs/functions). > Fluid compute is the default execution model for new Vercel projects, and it bills on Active CPU, Provisioned Memory, and Invocations. To learn more, read [Fluid compute](https://vercel.com/docs/fluid-compute). ## Definitions Before you apply the strategies below, it helps to define the concepts that drive Vercel Functions usage under Fluid compute. - **Invocation**: A [Vercel Function](https://vercel.com/docs/functions) runs in response to an event, such as an incoming request. Each trigger counts as one invocation. - **Active CPU**: The CPU time a function actively consumes, measured in milliseconds. Time spent waiting on I/O, such as a database query or an upstream API call, does not count toward Active CPU. - **Provisioned Memory**: The memory allocated to your function instances while they run, billed for the duration those instances are active. For configuration details, see the [Configuration Reference](https://vercel.com/docs/project-configuration#project-configuration/functions). ## With Next.js Next.js gives your team the flexibility to choose between different rendering methods. - [Static Site Generation (SSG)](https://nextjs.org/docs/basic-features/data-fetching/get-static-props) generates static content at build time, used through `getStaticProps` inside Next.js. - [Incremental Static Regeneration (ISR)](https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration) creates or updates content _without_ redeploying your site, used through `getStaticProps` and `revalidate` inside Next.js. - [Server-Side Rendering (SSR)](https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props) renders pages dynamically on the server, which is useful when the rendered data needs to be unique on every request. It is used through `getServerSideProps` inside Next.js. You can reduce your [Vercel Functions](https://vercel.com/docs/functions) usage with all the rendering methods above. Even [API Routes](https://nextjs.org/docs/api-routes/introduction) can use the Vercel [CDN](https://vercel.com/docs/edge-network/overview) to cache responses and serve content directly from close to your users. ### Static Site Generation If your page can use [SSG](https://nextjs.org/docs/basic-features/data-fetching/get-static-props) instead of [SSR](https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props), implement this approach to lower your usage. Vercel generates the page a single time at build time, and it cannot regenerate or replace the content after the build. Since your app no longer runs a function for every page request, which uncached [SSR](https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props) pages do, a page using [SSG](https://nextjs.org/docs/basic-features/data-fetching/get-static-props) triggers zero function invocations. ### Incremental Static Regeneration When a specific page needs to be regenerated periodically because of dynamic data, use [ISR](https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration) to lower the number of invocations your app performs. With this strategy, Vercel statically generates your pages and caches them on the [CDN](https://vercel.com/docs/edge-network/overview). A [Vercel Function](https://vercel.com/docs/functions) runs after a certain interval to refresh the cached content. By using [ISR](https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration), you lower the number of function invocations compared with uncached [SSR](https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props) pages. Your users also benefit from the speed improvements [ISR](https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration) gives, since your deployment serves content directly from the [CDN](https://vercel.com/docs/edge-network/overview). ### CDN caching and `stale-while-revalidate` If you cannot implement [ISR](https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration) or [SSG](https://nextjs.org/docs/basic-features/data-fetching/get-static-props), use [caching headers](https://vercel.com/docs/concepts/edge-network/headers) to store [SSR](https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props) pages on the [CDN](https://vercel.com/docs/edge-network/overview). One of the most useful headers is `stale-while-revalidate`, which serves stale content while the cache refreshes in the background. You can see an example of the header in a Next.js [SSR](https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props) page below. Note that you can also use this header for [Next.js API routes](https://nextjs.org/docs/api-routes/introduction), and if you need to apply the header to multiple paths, the [Next.js headers configuration](https://nextjs.org/docs/api-reference/next.config.js/headers) is also an option. ``export async function getServerSideProps(context) { const res = await fetch(`https://...`) const data = await res.json() context.res.setHeader('Cache-Control', 's-maxage=600, stale-while-revalidate=30') // set caching header return { props: {}, // will be passed to the page component as props } } export default function handler(req, res) { res.setHeader('Cache-Control', 's-maxage=600, stale-while-revalidate=30') // set caching header res.status(200).json({ name: 'John Doe' }) } module.exports = { async headers() { return [{ source: '/example/:id', headers: [ { key: 'cache-control', value: 's-maxage=600, stale-while-revalidate=30', }, ], }, ] }, }`` In the example above we tell the Vercel [CDN](https://vercel.com/docs/edge-network/overview) that the content is fresh for 600 seconds, and that it may continue to be served stale for up to an additional 30 seconds while a [Vercel Function](https://vercel.com/docs/functions) attempts an asynchronous validation. If validation is inconclusive, or if no traffic triggers it, the stale-while-revalidate function stops operating after 30 seconds, and the cached response becomes truly stale, so the next request blocks and is handled normally. Generally, you want to combine `s-maxage` and `stale-while-revalidate` to reach the longest total freshness lifetime your content can tolerate. For example, with both set to 600, the server must tolerate the response being served from cache for up to 20 minutes. Since asynchronous validation happens only when a request occurs after the response has become stale but before the end of the stale-while-revalidate window, the size of that window and the likelihood of a request during it determine how likely it is that all requests are served without delay. If the window is too small, or traffic is too sparse, some requests fall outside it and block until the deployment can validate the cached response. _The text above was inspired by_ [RFC5681](https://tools.ietf.org/html/rfc5861)_._ ## With Vercel Functions in `/api` If you are not using [Next.js](https://nextjs.org/), you can still apply strategies to lower the resources your deployment uses. ### CDN caching and `stale-while-revalidate` If your API returns data that can be shared publicly (without authorization headers or cookies), use caching headers to cache the function response on the Vercel [CDN](https://vercel.com/docs/edge-network/overview). One header worth highlighting is `stale-while-revalidate`. `module.exports = (req, res) => { res.setHeader('Cache-Control', 's-maxage=600, stale-while-revalidate=30') // set caching header res.status(200).json({ name: 'John Doe' }) }` ## Configuring your Vercel Functions You can customize the [region](https://vercel.com/docs/functions/configuring-functions/region), [memory](https://vercel.com/docs/functions/configuring-functions/memory), and [duration](https://vercel.com/docs/functions/configuring-functions/duration) of your functions. `{ "functions": { "api/example.js": { "maxDuration": 300 } } }` - **Memory**: Vercel bills Provisioned Memory for the memory allocated to your instances while they run. On Fluid compute, the CPU and memory configuration is either Standard (2 GB and 1 vCPU) or Performance (4 GB and 2 vCPU, available on Pro and Enterprise). CPU power scales with the memory tier, so choose Performance only when your functions are processing-intensive. Because waiting on I/O does not count toward Active CPU, I/O-bound functions already cost less by default. - **Region**: Another important configuration is the [region](https://vercel.com/docs/functions/configuring-functions/region) for your functions. If you do not deploy close to upstream dependencies or providers, latency can inflate the response time of your functions. By deploying closer to your database or API, your functions take less time to process a request, which lowers the Active CPU and Provisioned Memory your deployment uses overall. - **Duration**: By default, Vercel sets the duration of your functions to 300 seconds (5 minutes) on all plans. The maximum duration is 300 seconds on Hobby and 800 seconds on Pro and Enterprise, with a 1800-second (30-minute) extended maximum available in beta. See [function duration limits](https://vercel.com/docs/functions/limitations#max-duration) for the current values. Setting a reasonable `maxDuration` still bounds runaway executions so a function does not run for a long time without returning a response. You can adjust it through the [maxDuration config](https://vercel.com/docs/functions/configuring-functions/duration). - **Runtime**: Vercel Functions use the Node.js runtime by default, and they can also use Ruby, Python, Go, or any supported community runtime. For new projects, keep the Node.js runtime and rely on [Fluid compute](https://vercel.com/docs/fluid-compute) to reduce cold starts, improve concurrency, and make function usage more efficient. See the [runtime comparison](https://vercel.com/docs/functions/runtimes#runtimes-comparison) for help deciding which runtime fits your needs. ## Legacy pricing for projects not using Fluid compute Some projects still run on the legacy pricing model, which bills compute in GB-Hrs rather than Active CPU and Provisioned Memory. The definitions and advice below apply only to those projects. - **GB-Hrs**: The unit of measurement for legacy function execution. If one function with 1024 MB allocated takes one second to process a request, it used **1 GB-second**, which is **(1/3600) GB-Hrs**. For more detail, see ["What are GB-Hrs for Serverless Function Execution?"](https://vercel.com/guides/what-are-gb-hrs-for-serverless-function-execution). - **Lowering memory**: Under legacy pricing, if your function is I/O bound and waits on upstream providers often, lowering the allocated memory size reduces the overall GB-Hrs your deployment uses. Because CPU power scales with the configured memory, lowering the memory size is not advised for processing-intensive functions. A legacy configuration looks like this. `{ "functions": { "api/example.js": { "memory": 128, "maxDuration": 10 } } }` If your project still runs on the legacy model, you can enable [Fluid compute](https://vercel.com/docs/fluid-compute) to move to Active CPU, Provisioned Memory, and Invocations billing. For details on the older model, see [legacy pricing](https://vercel.com/docs/functions/usage-and-pricing/legacy-pricing).