June 6, 2026
Blink and your browser’s already there
How to make firecracker faster to start Chromium in < 20ms
Browser startup gets absurdly fast, and commenters want receipts from the competition
TLDR: Kernel says it can make Chromium feel almost instant by reusing pre-prepared browser setups instead of starting fresh each time. Commenters were impressed, but the real mood was: nice speed boost—now prove how it stacks up against rival browser providers.
A startup speed flex just dropped, and the comments instantly turned it into a tech sports debate. Kernel says it spent 14 months shaving Chromium startup times inside tiny virtual machines down to under 20 milliseconds—basically, faster than most people can blink. Their trick was simple in spirit, if wild in practice: do the boring setup once, freeze it, then stamp out lots of ready-to-go browser copies instead of starting from scratch every time.
That got readers excited, but also immediately suspicious in the most internet way possible: okay, but how does it compare to everyone else? One commenter flat-out asked whether Kernel is actually beating plain Firecracker and other browser infrastructure providers, which is classic comment-section energy: cool demo, now show the leaderboard. That was the strongest mood by far—admiration mixed with a demand for a cage match.
The other big reaction was nerdy awe over a little-known Linux feature called userfaultfd—basically a tool that helps load memory only when needed, so many browser copies can launch without all fighting over the same disk. One commenter called it a “slam dunk” and seemed genuinely delighted that someone finally showed a real-world use for it after years of obscurity. No huge flame war erupted, but the subtext was delicious: Kernel brought the speed brag, and the community brought the benchmarking pressure. The meme-y vibe? Somewhere between “my laptop could never” and “congrats, now race the rest of the industry live on stage.”
Key Points
- •Kernel says it reduced Chromium startup in Firecracker microVMs to under 20ms after 14 months of optimization.
- •The article describes replacing naive cold starts, which are limited by host disk read speed, with a snapshot-based flow that reuses generic initialization work.
- •Kernel takes snapshots after the VM and browser reach a reusable standby point, then injects per-instance identity data after forking and resuming.
- •Copy-on-write cloning of overlay disks and guest memory files reduces both disk I/O and storage growth when many VMs are forked from the same snapshot.
- •Using userfaultfd-backed paging and shared snapshot page cache allows hundreds of VMs to be launched in parallel, while hot pools provide prewarmed browsers for instant-feeling requests.