Wirewiki's autocomplete hits a 121ms budget across 240M domains

The author runs Wirewiki.com, a site for inspecting internet infrastructure such as DNS records, DNS delegation and email deliverability config. With many similar sites appearing, the author decided to compete on tool quality and UX, and picked the site's autocomplete, its main navigation method, as the place to prove it: the goal was for suggestions to feel instant, ready before the next screen frame.

The trick is timing the network request against the user's own typing rhythm. On keyDown, the moment a key is pressed, the client prefetches suggestions for the typed character plus a guess at the next one. On keyUp, when the key is released, it renders whatever came back. That gives the API a time budget equal to the first key press duration, plus the gap before the next press, plus the second key press duration: if the response lands before the user releases the second key, the suggestions are already there. The author measured this budget directly by timing themself typing 100 domain names and found it works out to a p99 of 121 milliseconds.

On the backend, the API is split in two. The head serves the top 1 million domains from the Tranco popularity list through an in-memory character trie, a prefix tree that precomputes the top 8 suggestions for every prefix; a lookup is a walk of a few pointers, worst case O(length typed). The tail covers the rest: CZDS supplies domain lists for most generic top-level domains such as .com, .net and .org (though not country-code domains like .uk, .de or .fr, which the author expects are covered anyway if they have meaningful traffic and thus appear in Tranco). Those 240 million domain names are sorted and delta-compressed into fixed-size blocks, occupying about 2.5 gigabytes on disk, indexed by a 27 megabyte in-memory directory. A tail lookup binary-searches that directory, then linearly scans one 256-name block; worst case O(length typed times log of the domain count). Because both the query length and the domain count are bounded, the author reasons both structures are effectively O(1) in practice.

To check the design under load, the author had an LLM generate a stress test: 720,000 keystroke queries simulating 60,000 typed domain names, replayed open-loop, meaning requests fire on a fixed schedule regardless of how quickly the server responds. Tested against the API alone, through Nginx, and end to end, most requests came back within 2 milliseconds from the API by itself, and Nginx plus the API answered within 15 milliseconds at p99 even at a sustained 1,600 requests per second.

The author considers the API itself close to optimal and not worth shaving further, since network latency dominates once real users are involved: in practice, total autocomplete latency comes out to roughly the round trip through Cloudflare to the server plus 10 milliseconds. Testing showed that round trip stays inside the 121 millisecond budget even with 1,000 simultaneous typists, but only because the single production server sits in Europe. Traffic from farther away, the author gives the US as an example, adds another 100 to 200 milliseconds, blowing past the budget at p99. CDN caching of frequently requested prefixes and the fact that Nielsen's usability research treats anything under 0.1 seconds as feeling instantaneous cover much of that gap in practice, though not enough to hit the strict target for everyone. A true global p99 of 0 milliseconds would need multiple geo-distributed servers with load balancing, which the author says they could build but consider excessive for this project; they call the whole system too niche to build a business around, while adding that they would reconsider if someone wanted to pay for API access.

Key facts

Suggestions are prefetched on keyDown and rendered on keyUp, giving the API a time budget of the first key press plus the gap plus the second key press; timing 100 typed domain names put that budget at a p99 of 121 milliseconds.
A two-tier backend covers 240 million domain names: an in-memory trie precomputes the top 8 suggestions per prefix for the top 1 million Tranco domains, while a 2.5 gigabyte SSD-backed block index, addressed by a 27 megabyte directory and 256-name blocks, covers the CZDS-sourced tail.
An LLM-generated load test of 720,000 keystroke queries from 60,000 simulated typed domain names, replayed open-loop, showed the API alone answering within 2 milliseconds typically, and Nginx plus the API within 15 milliseconds at p99 under 1,600 requests per second.
Real-world latency runs close to the Cloudflare round trip plus 10 milliseconds, which fits the budget from a single European server for nearby users but not for traffic from the US, which the author estimates adds 100 to 200 milliseconds.
Hitting a true global p99 of 0 milliseconds would require multiple geo-distributed, load-balanced servers; the author says that is too much effort for what they consider too niche a project to build a business on, though paid API access could change that.

Why it matters

The piece is a worked example of chasing sub-frame UI latency by engineering against the user's own timing rather than the network's. Instead of just trying to make the API fast, the author measured the actual budget available (two key presses and the gap between them) and built the backend to fit inside it, then verified the fit with a realistic load test rather than a guess. That discipline, measure the real constraint, design to it, then load test it, is the transferable part, independent of domain lookups specifically.

Who it affects

Mainly other engineers building autocomplete, search-as-you-type, or similar low-latency lookup UIs over large datasets; the trie-plus-block-index split and the prefetch-on-keyDown pattern are both reusable outside domain names. More narrowly, it affects users of Wirewiki.com itself, the DNS and domain inspection tool the autocomplete belongs to.

How to use it

Wirewiki.com's autocomplete is live and usable today; the article itself doubles as a public demo readers can type into. There is no product or API being sold: the author states this is too niche to turn into a business, but says they would reconsider building paid API access to the underlying domain lookup if someone wanted it, with no pricing or timeline given.

How solid is it

The claims rest on the author's own measurements rather than third-party benchmarking, but the methodology is specific and reproducible: a self-timed 100-domain typing test for the keystroke budget, and an LLM-generated 720,000-query open-loop load test against the API alone, through Nginx, and end to end, with concrete latency figures at each stage (2 milliseconds typical from the API, 15 milliseconds at p99 through Nginx at 1,600 requests per second).

Risks and caveats

The headline claim carries its own asterisk: the true p99 0 millisecond target is not actually met globally, only for traffic close to the single production server in Europe. Distant traffic, the US is given as an example, adds an estimated 100 to 200 milliseconds and exceeds the budget at p99, papered over in practice by CDN caching and the fact that under 0.1 seconds generally feels instantaneous to users. Reaching the strict target everywhere would need a geo-distributed, load-balanced deployment the author has decided not to build for what they consider a niche side project.

“I could set up multiple servers and geo load balance traffic. That would give me the p99 0 ms* latency. But that's a bit much. Even for me.”

— the developer behind Wirewiki.com