Cloudflare has slashed cold start delays in its Workers platform by 10 times using a technique called worker sharding. The improvement means that 99.99% of requests now hit already-running code instances instead of waiting for initialization. This breakthrough addresses a critical pain point in serverless computing where applications must completely initialize before handling requests.

Cold starts occur when serverless code must initialize before handling a request, involving four phases: fetching JavaScript from storage, compiling to machine instructions, executing top-level initialization, and finally invoking the code. Cloudflare's original solution masked cold starts by pre-warming Workers during TLS handshakes, but this became ineffective as cold starts grew longer and TLS handshakes became faster. Script size limits expanded from 1 megabyte to 10 megabytes for paying customers, and startup CPU time limits increased from 200 milliseconds to 400 milliseconds.

The new solution routes all requests for a specific application to the same server using a consistent hash ring. This approach keeps Workers active in memory for low-traffic applications, reducing cold start rates from 100% to nearly zero. The system introduces two server roles: shard clients that initially receive requests and shard servers that serve as the home for specific Workers. This architecture frees memory for other applications while maintaining warm instances for frequently used code.