# How can I improve function cold start performance on Vercel? **Author:** Lee Robinson --- Vercel Functions let you write server-side logic that connects to your database or external APIs. When a function starts for the first time, that first invocation is a cold start, and later requests to the same warm instance skip that startup cost. Fluid compute is the default execution model for Vercel projects created since April 23, 2025, and it includes automatic optimizations that reduce how often cold starts happen and how much they cost when they do. Because of this, most production requests land on an instance that is already running, and a latency increase often has a different cause. This guide helps you confirm whether startup time is actually the cause before you spend effort optimizing for it. ## How Fluid compute reduces cold starts Fluid compute changes how your functions run so that a cold start is the exception rather than a cost you pay on every request. Projects created since April 23, 2025 use it by default, and older projects can enable it in their project settings. Fluid reduces how often cold starts happen through several mechanisms working together: - **Optimized concurrency.** Multiple invocations share a single warm instance instead of spinning up a new instance per request, so new requests reuse a function instance that is already running whenever capacity is available. - **Bytecode caching.** On Node.js 20 and later in production deployments, Vercel pre-compiles your function code so the runtime spends less time parsing and evaluating it on startup. - **Pre-warmed instances.** On paid plans, production deployments keep instances warm and ready so incoming traffic is more likely to land on a running instance. - **Automatic concurrency scaling.** Vercel proactively adds capacity ahead of demand, scaling up to 30,000 concurrency on Hobby and Pro and 100,000 or more on Enterprise. You can read how this works in [automatic concurrency scaling](https://vercel.com/docs/functions/concurrency-scaling#automatic-concurrency-scaling). These optimizations amortize startup cost across many requests instead of charging it on each one. You can measure your own cold start percentage in [Observability](https://vercel.com/docs/observability). ## Diagnose the cause before optimizing Before you change anything, confirm that startup time is actually driving the latency you see. Slow responses often come from the work a function does rather than how it starts, so treat a cold start as a diagnosis question, not the default explanation. Use the [Observability tab](https://vercel.com/docs/observability) to check three things: - **Function startup performance.** See how long your functions take to become ready. - **Percentage of cold starts.** Confirm whether cold starts make up a meaningful share of your traffic or a small fraction of it. - **Latency to external APIs.** Measure time spent waiting on databases and third-party services, which is a common source of latency that startup optimizations will not fix. If the data shows that external calls or in-function work dominate the latency, focus there. For a deeper look at where time goes inside an invocation, see [debug slow functions](https://vercel.com/docs/functions/debug-slow-functions). ## Troubleshooting confirmed cold start latency If Observability confirms that startup time is the cause, check for the following cases. Low-traffic functions get fewer chances to reuse a warm instance. Archived functions add at least one second of latency on the first invocation after an idle period, because functions archive after two weeks idle in production and 48 hours in preview. Projects that do not yet use Fluid compute miss its automatic optimizations. The steps below reduce startup time in those cases. ### If your project predates the default, enable Fluid compute Projects created before April 23, 2025 do not use Fluid compute automatically. Enabling it gives your functions optimized concurrency, bytecode caching, pre-warmed instances, and automatic concurrency scaling. See [Fluid compute](https://vercel.com/docs/fluid-compute) for how to turn it on. ### Choose the closest region for your functions Functions deploy to `iad1` (US East) by default. You can [change the default region](https://vercel.com/docs/functions/configuring-functions/region) in your project settings. Pick a region close to your data source so your functions spend less time waiting on the network. ### Choose smaller dependencies Startup time correlates with function size, and most of that size usually comes from external dependencies. Large dependencies take longer to parse and evaluate, sometimes seconds or more. Review your bundle with a [bundle analyzer](https://nextjs.org/docs/app/guides/package-bundling) and remove the heaviest packages you can. ### Use caching headers You can cache function responses with `Cache-Control` headers, which helps repeat visitors and takes load off your functions. Vercel's cache also supports `stale-while-revalidate`. Keep in mind that cache misses still fetch from your origin, such as your database, rather than reading from the cache. ### Update to the latest version of Next.js Recent versions of Next.js include startup performance improvements, especially when you use external packages like Sentry. Upgrading picks up those gains without further changes. ### Bundle external dependencies on the Pages Router If you use the Pages Router, set `bundlePagesExternals` to `true` under the `experimental` flag. This bundles external dependencies and reduces cold start time for Pages Router applications. ### Use dynamic imports for divergent code paths For the uncommon case of a site with divergent code paths, dynamic imports load only the code a given request needs. Loading less code up front reduces the work done during a cold start. ## Next steps - [Fluid compute](https://vercel.com/docs/fluid-compute) - [Automatic concurrency scaling](https://vercel.com/docs/functions/concurrency-scaling#automatic-concurrency-scaling) - [Debug slow functions](https://vercel.com/docs/functions/debug-slow-functions) - [Vercel Functions](https://vercel.com/docs/functions) - [Observability](https://vercel.com/docs/observability) --- [View full KB sitemap](/kb/sitemap.md)