Latency Ladder runs four live micro-benchmarks in your browser and plots them on a single logarithmic scale: CPU cache, main memory (RAM), IndexedDB, and a network round-trip. Instead of repeating the well-known "latency numbers every programmer should know" chart, which was measured years ago on hardware you have never used, it measures your own device right now and shows how many cache or RAM accesses fit inside a single network round-trip.
The classic reference figures are roughly 1 ns for an L1 cache reference, 100 ns for a main-memory read, and 100 µs to 100 ms for storage and network round-trips. They are a useful mental model, but they describe one machine from over a decade ago. Latency Ladder measures the same tiers on your device so you see your own numbers.
On most machines main memory is tens to a few hundred times slower than an L1 cache hit. A cache read lands around a nanosecond; a RAM read that misses every cache is usually 60 to 150 ns. Run the ladder and the RAM bar shows your exact ratio against cache.
It uses a pointer-chasing kernel compiled to WebAssembly. Each read address depends on the value just read, so hardware prefetchers and the JIT cannot hide the real latency. The same kernel runs against a small working set that stays in L1 (cache) and a large one that spills to main memory (RAM). Many trials are reduced with a trimmed mean to absorb GC pauses and scheduling jitter.
They are honest order-of-magnitude measurements, not lab-grade figures. Browser timers are deliberately coarsened for security, and a shared tab is a noisy place to benchmark, so treat the numbers as "your device, roughly" rather than a datasheet. Repeated runs on the same machine stay within single-digit percent of each other.
No. Everything runs client-side. The network tier fetches a small file from this page's own origin, and nothing you measure ever leaves your browser.