A cold start is the delay before an application can serve work when no prewarmed instance exists. For containers, startup work includes obtaining the image and initializing its environment. Wasm containers can reduce that delay because they load the application rather than a full userspace environment. section 1.2.2 section 7.3.2
Image composition is a practical cause of the difference. A typical Docker image packages an application with an operating-system userspace, while a Wasm image can begin from an empty image and contain only application logic and needed dependencies. Smaller artifacts reduce the data that must be pulled, helping deployment and startup. section 1.2.2 section 7.3.2
Figure 1.5 Dockerfiles for a Docker container and a Wasm container
Compare the Dockerfiles to see why a Wasm image can omit the Ubuntu base layer: the Wasm container starts from an empty image, while the Docker container includes an OS layer. section 1.2.2
Cold-start gains have useful limits and trade-offs:
- A cited comparison reports a Wasm-container cold start about 160% faster than a Docker-container cold start, alongside images often 80% smaller. section 1.2.2 section 7.3.2
- Wasm’s single-threaded nature can limit throughput under stress; a runtime may instead handle requests by starting separate Wasm instances. section 1.2.2
- Docker can also avoid an OS layer by using a static native binary with FROM scratch, so the contrast is not exclusive to Wasm. section 1.2.2
Running a small Wasm container
Build a wasi/wasm32 OCI image, import it into containerd, then run it with the Wasmtime containerd runtime. The resulting hello container demonstrates the lightweight artifact whose lack of userspace initialization supports faster cold starts. section 7.3.2 section 7.3.2
