Cutting Serverless Cold Starts Without Abandoning Serverless

Runtime choice matters more than most teams expect: a compiled or lighter-weight runtime typically initializes faster than one that has to start a full virtual machine or interpreter with a large standard library. Package size matters too, since a function bundling a huge dependency tree has more code to load before it can run, and a lot of that code may not even be used on the request path.

Anything the function does in its initialization code before handling the first request, like establishing a database connection pool sized for steady-state load, adds directly to cold start time.

Reduce package size by removing unused dependencies and using a bundler that tree-shakes anything not actually imported. Move expensive initialization, like large SDK client setup, to lazy-load only when the specific code path that needs it actually runs, instead of unconditionally on every cold start regardless of which handler gets invoked.

For a runtime with multiple flavors, check whether a lighter one gets you most of the way there before reaching for anything that costs money.

Provisioned concurrency keeps a set number of execution environments warm and ready, eliminating cold starts entirely for the traffic that fits within it, at the cost of paying for that capacity whether it's actively serving requests or not.

It's a reasonable fix for a predictable, latency-sensitive path, like a checkout API where a slow first response directly costs revenue. It's a poor fit for a rarely-called, latency-tolerant function, like an overnight batch job, where you'd be paying continuously for warm capacity a cold start would barely be noticed on.

• Have you already trimmed package size and lazy-loaded expensive initialization? Provisioned concurrency on an unoptimized function is paying to mask a problem you could have fixed for free.
• Is this specific function on a latency-sensitive path where a user or another system is waiting synchronously, or is it something that runs in the background where a cold start's delay genuinely doesn't matter?
• Is the traffic pattern predictable enough that provisioned concurrency's fixed capacity matches real demand, or would you be paying for warm capacity that sits idle most of the time?

If a workload has grown into a steady, predictable, always-on traffic pattern, the case for serverless in the first place, paying only for what you use, starts to weaken regardless of how well you've mitigated cold starts. At that point, a small always-on container or a traditional server for that specific workload can end up both faster and cheaper than a heavily provisioned serverless function fighting its own architecture.

Say a routine dependency update quietly pulls in a much larger transitive dependency, and cold start times creep up noticeably over the following weeks without anyone connecting the two events. Nobody changed the function's own code, so the instinct is to look everywhere except the dependency tree.

Comparing package size before and after the update, not just eyeballing the diff for logic changes, is what actually surfaces this kind of regression. Treat package size as a metric worth tracking over time on latency-sensitive functions, the same way you'd track response latency itself, rather than something you only check when a cold start problem has already become visible to users.

Pinging a function on a schedule to keep an instance warm is a common, low-effort mitigation, and it genuinely helps for low-traffic functions with predictable idle gaps. Its limits show up fast under real concurrency: a warmup ping keeps one instance warm, but a burst of simultaneous requests still needs additional cold instances to scale beyond whatever the ping is holding ready. Treat warmup pings as a stopgap for a specific known gap in traffic, not a substitute for provisioned concurrency once a path genuinely needs guaranteed low latency under load.