Cold starts are an unavoidable part of serverless computing. When an idle function wakes up, the request waits for runtime initialization, dependency loading, and network handshakes. Early HanCloud deployments took about 1.8 seconds—long enough to feel sluggish. Here is how we reduced that delay to 400 milliseconds.
Start with a flame graph
Optimization starts with measurement. Fine-grained spans split the 1.8-second cold start into image download, runtime initialization, dependency resolution, and user-code execution. The largest cost, unexpectedly, was outside the user code.
- Image download and extraction: about 700 ms, entirely serial
- Runtime initialization: about 600 ms, starting from scratch each time
- Dependency resolution: about 350 ms, repeatedly loading the same modules
- First user-code execution: about 150 ms
Three complementary techniques
Once the bottlenecks were clear, we optimized each stage separately: layered images reuse and pre-position common base layers, a warm pool keeps initialized instances ready during quiet periods, and runtime snapshots restore initialized memory instead of repeating the full cold-start sequence.
Performance work is measurement: find where every millisecond goes, then win it back one stage at a time.
Runtime snapshots delivered the largest gain. They capture the entire process after initialization but before its first request, so restoring the snapshot skips initialization entirely:
// Freeze the runtime state at the initialization completion point const snapshot = await runtime.snapshot(); await store.put(fnId, snapshot); // Restore directly during cold start, skipping initialization const restored = await runtime.restore(snapshot); return restored.handle(request);result
Together, the three changes brought P50 cold starts below 400 milliseconds and kept P99 near 700 milliseconds. More importantly, the path is now observable and regression-tested, so monitoring surfaces degradation immediately. That is the guardrail we actually needed.