I really don't like that diagram. The folks doing serverless work at University of Wisconsin-Madison generally do a good job, but they really whiffed on that one.
I don't think there's a reasonable sense in which KVM/Qemu moves more functionality to the guest kernel than KVM/Firecracker does. Both depend on the guest kernel for VM setup (KVM), low-level virtualization operations (KVM), and doing the actual IO below their paravirtualized device drivers. On the other end, Linux containers don't have a guest kernel (unless you use some kind of library OS). So those boxes should collapse together. If you look at it one way, gVisor is a guest kernel, which depends on the host kernel in fundamentally similar ways to what Firecracker or Qemu do.
I took the diagram to just mean the whole guest, not just the kernel. In the qemu case, the guest has to interact with the bios and other emulated peripherals. Firecracker skips the whole bios layer so it does operate at a different layer
The biggest impact is not to have JS and not to have a giant amount of HTML / CSS. That keeps the content very small. The syntax highlight is rendered at compile time.
Interestingly HN's front page is an order of magnitude smaller in uncached transfer size. It does include some JS, but the lower perceived snappiness seems to owe to longer round trip times (for me anyway ~60ms for HN vs ~10ms for dev.l1x.be).
But Firecracker is VMs, not containers.
