The illusion of "zero latency" web apps
Flawed performance metrics drive engineers to manipulate telemetry and fake zero latency, producing sluggish web apps that break for billions of users.
By Wren Okada
Sparked by P99 0 ms* autocomplete for 240M domain names · discussion
Recently, I noticed that highly praised modern web apps feel noticeably sluggish to type in, despite marketing copy claiming they are exceptionally fast. Historically, subjective impressions of UI speed are terrible proxies for reality because human timing is heavily distorted by animation framerates and placebo effects, so my default is to assume these biological intuitions are incorrect until someone produces raw trace logs or video evidence to prove the delay exists. However, a recent artifact perfectly captures why my sluggishness intuition is actually physically correct here. Last week, I was reading a post about a P99 0ms autocomplete API, which was widely praised on HN as a triumph of performance engineering. The enthusiasm for this metric reveals a fundamental industry delusion where engineers equate a manipulated telemetry hook with actual physical reality.
Let's trace the literal hardware-to-pixel timeline of a single keystroke to see how this sleight of hand operates. When a user presses a physical key, the browser doesn't magically register an input at T=0. As Dan Luu measured in his keyboard latency tests, the physical switch debounce, USB polling intervals, and OS interrupt handling silently add 20ms to 50ms of delay before the browser's main thread is even aware a physical switch was actuated.
To break that math down: a standard USB polling rate might be 125Hz (adding an expected value of 4ms and a maximum of 8ms of delay, depending on when the physical actuation falls in the USB polling window). Switch debounce logic adds another 10ms to 20ms just to ensure the physical metal contact is stable before signaling, and then the OS kernel has to handle the hardware interrupt via the APIC. On top of that, modern CPUs—particularly in laptops and phones—aggressively utilize power-saving C-states. Waking a CPU core from a C8 sleep state to service that interrupt can cost another 1ms to 3ms. Once awake, the OS scheduler has to context-switch the browser's main thread back onto a core. If the main thread is currently blocked by an advertising tracker's JavaScript loop, this adds another highly variable 5ms to 15ms. We are looking at a baseline tax of 4ms + 15ms + 2ms + 10ms = 31ms before the JS event listener even fires. This overhead is completely unavoidable on standard consumer devices.
The mathematical trick driving these allegedly zero-latency software setups relies on exploiting a quirk of human biology. According to research on keystroke dynamics, the physical dwell time (the gap between a finger pushing a key down and lifting it back up) averages 70ms to 150ms. The mechanism driving these seemingly instantaneous web inputs is to initiate the network prefetch on the keyDown event, but only start the application's telemetry clock on the keyUp event.
If we do the raw arithmetic here, the deception becomes obvious. A user starts pressing a key at T=0. The hardware and OS delay takes us to T=31ms, where the keyDown event finally fires and the background network request begins. The user continues holding the key down for a perfectly average 100ms biological dwell time. At T=131ms, the key is released, keyUp fires, the telemetry metric starts logging, and the already-resolved network payload is painted to the DOM in 0ms. The Datadog dashboard records an absolute zero.
That dashboard is reporting a completely fabricated reality.
The human being sitting in the chair waited 131ms between physical intent and visual feedback, yet the metric-gathering apparatus actively colluded to hide an entire tenth of a second of physical delay. (This phenomenon also appears elsewhere, as seen with Largest Contentful Paint (LCP), where teams realize that lazily rendering a microscopic 1-pixel transparent image immediately at page load tricks the Chromium telemetry into stopping the LCP timer, even if the actual text payloads that the user cares about take an additional 4000ms to render).
The strongest counter-argument to this observation is that this is simply a clever, victimless optimization: if a developer can fire off a background network request early to mask network overhead, who cares if the telemetry metric is slightly artificial? If the user gets their visual result exactly as their finger leaves the key, the prefetch worked, which forces anyone arguing against this technique to awkwardly demand architectural purity over perceived speed.
That argument fails because the web is not exclusively navigated by English speakers using standard desktop keyboards. By structurally coupling core application logic to raw hardware-adjacent key events rather than the actual W3C standard input event, developers are shipping code that is empirically broken for billions of users. The input event correctly fires when the actual value of a text field changes, natively handling the extreme complexities of how different operating systems manipulate text buffers. But standard input doesn't give you a 100ms biological dwell time buffer to hide your network request, so performance-hacking architectures ignore it.
Instead, they bind to key events, which guarantees a catastrophic failure mode. As the MDN specification for KeyboardEvent outlines, Input Method Editors (IMEs) used for CJK languages (alongside mobile swipe keyboards and voice-to-text systems) frequently bypass standard keydown sequences entirely. Typing on a Japanese keyboard involves complex sequences that completely bypass standard 1:1 key mapping; for example, typing ka might temporarily display か, and pressing space might trigger a background OS prediction engine that converts it to 家 or 蚊. During this entire composition phase, the OS is intercepting the physical keys. When these systems do eventually emit a key event, they typically emit a synthetic keyCode 229 to indicate that the input is being actively processed by the OS-level IME buffer.
If your allegedly lightning-fast autocomplete logic is hardcoded to listen for standard ASCII key sequences to trigger its prefetches, it simply fails to fire for anyone typing on an Android device or using a Japanese IME. The 0ms autocomplete is infinitely slow because it never actually triggers, leaving a massive portion of the global user base staring at a broken UI state.
We are left with an architectural pattern that takes tens of milliseconds longer than it should, lies on the performance dashboard by a full order of magnitude, and completely breaks core OS input methods for most of the planet. And yet, this pattern is relentlessly celebrated by highly paid engineers at massively valued tech companies. To understand why smart people deliberately ship broken systems, we have to move up the stack from DOM event handling to organizational mechanism design. The tech industry's handling of web latency is a textbook example of The Market for Lemons.
Akerlof's classic economic framework relies on buyers being utterly blind to underlying product defects while sellers retain perfect visibility, and the modern software organization provides an identical structural dynamic. Management (the buyer of the engineering labor) cannot easily measure the physical latency of a keyboard switch on an end-user's desk in another hemisphere, but they can instantly pull up a Datadog dashboard. Engineers (the sellers) are locally optimizing for the highly legible metric that dictates their compensation. If an engineer implements a technically correct architecture using the robust input event, the dashboard will log the full network round trip (resulting in a 150ms latency metric) and the engineer will get a poor performance review for shipping a sluggish feature.
If an engineer hacks the event listener to start on keyDown and stop the clock at keyUp (a choice that actively punishes mobile users, even though mobile traffic constitutes the overwhelming majority of modern web usage), they get to ship a graph showing 0ms latency and receive a promotion for an ostensibly miraculous technical achievement. The fact that the application is now a sluggish, inaccessible lemon for a mobile user in Tokyo is irrelevant to the internal economics of the company.
If you were to ask management, abstractly, if they want to ship a product that feels sluggish and is completely broken for mobile swipe users, I suspect they'd tell you no. But insofar as a company can be said to want anything, it wants what it incentivizes. As long as performance reviews are tied to a Datadog dashboard that stops the clock at keyUp, the market will continue to efficiently route around physical reality to produce exactly the broken, '0ms' illusions we asked for.