Zero Cold Starts Are Now a Default on Cloudflare Workers
Cold starts have long been the unwelcome side effect of serverless computing. When a function hasn't been invoked recently, the platform must spin up a fresh instance before it can handle a request, injecting unpredictable latency into execution. On container-based platforms, that warm-up can stretch into full seconds. Providers offer workarounds—typically synthetic "keep-alive" pings that carry their own costs and complexity—but the underlying problem remains.
Cloudflare Workers has avoided the worst of this through its isolate-based runtime, which can initialize a Worker in under 5 milliseconds. Even so, that wasn't a guarantee: a cold Worker still had to load and compile after the first request arrived. As of today, that's no longer the case. Cloudflare has rolled out an optimization that eliminates cold starts for Workers entirely, with no extra fee and no configuration changes required.
Why Cold Starts Happen
Keeping every function resident in memory at all times is impractical, so serverless providers typically load a function only after the first request. When the function goes idle, it's evicted, and the next request starts the cycle again. This creates unpredictable execution times that degrade the user experience—an unacceptable trade-off for the benefits of serverless.
Reusing the TLS Handshake to Warm Up Early
The fix leverages a step that already happens before most requests even arrive. Roughly 95% of Worker traffic is HTTPS, and every HTTPS connection begins with a TLS handshake. During that handshake, clients send a ClientHello packet that includes the hostname via the Server Name Indication (SNI). Previously, a Worker wasn't loaded until the handshake had fully completed—two round-trips between client and server.
Cloudflare's engineering teams realized the hostname was available at the very start of that exchange. Instead of waiting for the handshake to finish, the network now hints the Workers runtime to eagerly load the corresponding Worker the moment the ClientHello is received. By the time the handshake concludes, the Worker is already warm and ready to execute. Since loading a Worker takes roughly 5 milliseconds and the typical round-trip latency between a client and Cloudflare's network exceeds that, the cold start effectively becomes zero.
Availability and Current Limitations
This optimization is live in production and available to all Workers customers immediately. No pricing changes or configuration updates are involved. The one current constraint is that it applies to Workers deployed to a root hostname—example.com, for instance—rather than to specific paths like example.com/path/to/something. Cloudflare says future optimizations will target path-level preloading.
Beyond Cold Starts
Cloudflare also points to the recently announced Workers Unbound beta as part of the broader performance picture. Combined with the zero-cold-start runtime, the platform now offers Workers with no CPU limits across a network spanning more than 200 cities. For developers interested in exploring further, Cloudflare points to its Python and Kotlin Worker examples on GitHub as a starting point for testing the platform's expanded language support.
