The first user to hit your app after a period of inactivity pays a tax. The runtime needs to boot — spin up a container, load dependencies, establish database connections. This is the cold start, and it determines whether your first visitor waits 200ms or 3 seconds.
We triggered cold starts by letting each platform go idle for 15 minutes, then sending a single request. Repeated 200 times per platform over 48 hours to capture variance. The numbers below aren't lab conditions — they include real-world jitter, DNS resolution, and TLS negotiation.
Lower is better. Time in milliseconds from request to first byte.
The tail matters. A p50 of 400ms can hide a p99 of 2.8 seconds.
| Platform | p50 | p95 | p99 | Min | Max | Samples |
|---|
A cold start under 500ms is barely noticeable. Between 500ms and 1 second, users perceive the delay but tolerate it. Above 1 second, you're losing people — Google's research shows 53% of mobile users abandon pages that take longer than 3 seconds to load, and a cold start is just the server portion.
The platforms that score well here (OpenKBS, v0) run on infrastructure designed for fast cold starts — AWS Lambda and Vercel Edge Functions, respectively. The platforms that score poorly are running on shared containers or proprietary runtimes that weren't optimized for this scenario.
Watch the p99, not the p50. Median tells you the common case. The 99th percentile tells you what your unluckiest users experience. A 2.8-second p99 means 1 in 100 visitors waits nearly 3 seconds before seeing anything. On a landing page, that visitor is gone.
Cold starts were triggered after a 15-minute idle period. Each test sent a single authenticated GET request to the app's main page and measured TTFB. Tests ran from a single us-east-1 origin to isolate server-side performance from geographic latency. Full methodology →