The real cost of serverless cold starts
Cold starts have always been the weak point of serverless. The problem isn't merely the delay itself — it's when that delay occurs. New visitors, traffic surges and first interactions tend to trigger cold starts, exactly the moments when performance matters most.
Traditional serverless providers shut down idle instances after a short period to control costs. When traffic returns, those instances must be rebuilt from scratch, causing multi-second delays. That leaves developers with an uncomfortable trade-off: accept unpredictable performance or pay for dedicated servers that run continuously.
Vercel's Fluid compute is designed to remove that choice. The platform reports zero cold starts for 99.37% of all requests, and the rare exceptions are faster and shorter-lived than what traditional serverless platforms deliver. That result comes from a combination of platform-level techniques that work at any scale.
Understanding the cold start bottleneck
A cold start occurs when a serverless function must initialize from zero state to handle a request. The platform allocates compute resources, loads application code, initializes the runtime, and establishes network connections — a process that can take several seconds. End users see loading spinners, blank screens, or unresponsive interfaces during what should be instant responses.
Even after that initial hit, cold starts create practical problems for dev teams. They do not reproduce in local development where processes stay warm, and they're inherently intermittent, making them difficult to monitor, debug, and explain to stakeholders.
Constant readiness: preventing cold starts before they happen
Most serverless platforms scale instances to zero during idle periods. Vercel applies a different baseline policy for production deployments on Pro and Enterprise plans: it always keeps one instance warm.
Scaling to one instead of to zero means a qualifying deployment never makes its first visitor wait for instance initialization. It applies automatically to single-region functions, middleware, and multi-region functions, and requires no configuration. This pre-warming alone prevents about a third of all potential cold starts.
The real-world difference is visible in common scenarios. A startup sharing a preview build with a small testing group, a team waiting hours between stakeholders logging in, or an enterprise rolling out a feature for executive review in off hours — all get version page-load speeds instead of a 3-4 second cold start on a first visit.
Scale to one applies under these conditions:
- Pro and Enterprise plans: current production deployment, kept warm if invoked in the preceding 14 days
- Enterprise plans: most recent branch deployment, kept warm for up to three days
Because instances remain warm rather than continuously running, there is no charge for idle time. Scale to one is effectively free, unlike dedicated servers.
Addressing cold starts from every direction
Beyond permanent warmth, the platform's full cold start strategy covers five fronts:
- Prevention: scale to one keeps an instance warm before it is needed
- Frequency reduction: Fluid compute multiplexes existing instances across requests
- Anticipation: predictive scaling warms instances before demand grows
- Impact reduction: bytecode caching shortens unavoidable cold starts
- Release management: rolling releases avoid cold start spikes caused by deployments
Concurrency: turning instances into multiple use hosts
Fluid compute changes the instance model itself. Traditional serverless runs one instance per request in-flight; a burst of 100 requests can trigger 100 independent instance starts. Fluid compute instead lets a single instance serve many concurrent requests. Rather than treating requests as isolated units needing unique resources, functions can handle simultaneous traffic without cross-request interference.
With that model, 100 requests might be handled by a handful of already-warm instances, and an instance that is awaiting an AI or database response can take on additional work concurrently. Traffic routes to existing capacity first, and new instances only spawn if there's genuinely no room.
Production observations show instances regularly handling dozens of requests at once, with peaks above 250 concurrent requests per instance. Most instances handle at least 3 concurrent requests, and many process 11 or more simultaneously. Since new instance starts correspondingly drop, cold start opportunities become rare. Active CPU pricing means users pay for code actually executing, not for time spent waiting.
Warming ahead and compiling faster
Not all traffic is unpredictable. Predictive scaling observes recurring demand patterns and provisions instances before those patterns arrive. Rather than reacting to load after it rises, functions are already warm for regular cycles of usage — daily traffic waves, scheduled events, or known busy periods — without the developer configuring a single scaling rule.
For the small share of requests that truly need a fresh instance, bytecode caching eliminates one of the most costly parts of initialization. JavaScript requires parsing and compilation into bytecode before any code runs. Bytecode caching preserves that compiled work from the first execution, so subsequent starts skip the compilation stage almost entirely.
The implementation is specific to Vercel's runtime: rather than presenting a temporary filesystem for cache storage, Vercel merges bytecode chunks from different routes and lazy-loaded modules into a comprehensive cache. When traffic touches /home and /blog, for instance, separate caches get merged into a coherent store. The benefit deepens as the application's code paths get exercised more.
Smoothed releases: avoiding deployment spikes
Deployments add yet another cold start source, orthogonal to request patterns. With an instant atomic swap, 100% of production traffic suddenly points at brand new instances on code with no warm cache state, so every user simultaneously takes a starting penalty. Nothing in traffic forecasting can prevent it, because the burst is tied to the deployment cycle, not to load.
Rolling releases reshape the switch-over into a managed, gradual migration. Small amounts of traffic hit the new deployment first, as Fluid compute starts routing those requests to warm instances of the latest code. As rollout percentage increases step by step, concurrency handles the partial load and predictive scaling readies new capacity. When the deployment completes, it retains a stable population of warm producers instead of slamming users
