Cold Start
A cold start occurs when a serverless function is invoked after being idle. The platform must provision a new execution environment — loading the runtime, initializing dependencies, and establishing connections — before your code can handle the request. This initialization adds 100ms to 10+ seconds of latency.
Why Cold Starts Happen
Serverless platforms scale to zero when there’s no traffic. When a request arrives:
- Provision a container or isolate — allocate compute resources
- Load the runtime — start Node.js, Python, Go, etc.
- Load your code — download and parse your function bundle
- Initialize dependencies — execute top-level imports and module initialization
- Establish connections — connect to databases, caches, external services
- Process the request — finally, your handler code runs
Steps 1–5 are the cold start. Subsequent requests reuse the warm environment and skip directly to step 6.
Cold Start Duration by Platform and Runtime
| Platform | Node.js | Python | Go | Java |
|---|---|---|---|---|
| AWS Lambda | 200–500ms | 200–500ms | 50–100ms | 1–5s |
| Google Cloud Functions | 300–800ms | 300–800ms | 100–300ms | 3–10s |
| Vercel | 100–300ms | — | — | — |
| Cloudflare Workers | <5ms | — | — | — |
Compiled languages like Go start fastest. JVM-based languages like Java have the longest initialization times.
How to Minimize Cold Starts
- Keep function bundles small — fewer dependencies means faster initialization
- Use provisioned concurrency — pre-warm instances on AWS Lambda
- Choose fast runtimes — Go and Rust have minimal cold starts
- Avoid heavy initialization — lazy-load dependencies that aren’t needed for every request
- Offload long work to a task queue — keep functions fast so cold start overhead stays minimal relative to total execution time