De kunst van razendsnel: zo bouw je domein-autocomplete

De kunst van razendsnel: zo bouw je domein-autocomplete

Jun 25, 2026 web performance dns api design ux optimization developer tools

Waarom instant aanvoelen belangrijker is dan je denkt

Herken je dat: je typt iets en de suggestie verschijnt nog voor je de toets loslaat? Dat is geen tovenarij—dat is pure techniek. En het wordt een stuk interessanter als je rekening houdt met 240 miljoen domeinnamen.

De psychologie van snelheid

Gebruikers willen direct resultaat. Onderzoek van Nielsen Norman Group toonde aan dat 0,1 seconde de grens is waarboven mensen hun actie nog als instant ervaren. Alles daarboven voelt traag aan en breekt de concentratie.

Bij Wirewiki is de autocomplete de eerste interactie die gebruikers hebben. Elke milliseconde telt als je snel DNS-records opzoekt. De tool moet aanvoelen alsof hij je gedachten leest—niet alsof hij wacht op een server.

De truuk met prefetching

Het mooie zit hem hier niet in het versnellen van de API (hoewel dat helpt). Het echte geheim is dat je tijd steelt van het typroces zelf.

Bij elke toetsaanslag (keyDown) vraag je alvast suggesties op voor wat de gebruiker typt én de meest waarschijnlijke volgende letter. Bij het loslaten (keyUp) toon je wat er klaarstaat. Daardoor wordt je tijdbudget niet bepaald door API-latentie, maar door de duur van twee toetsaanslagen plus de pauze ertussen.

Op een 60Hz scherm heb je 16,7ms per frame. Voor snelle typers (p99) kom je uit op zo'n 121ms. Dat is je venster. Zorg dat resultaten klaarstaan vóórdat de tweede toets losgaat, en voor de gebruiker voelt het instant aan.

Schaalbaar ontwerpen

De API moet 240 miljoen domeinen aankunnen zonder te haperen. De slimme aanpak: behandel populaire domeinen anders dan de rest.

De koplopers: Topdomeinen staan in een character trie, volledig in het geheugen. Prefix-zoekopdrachten zijn simpelweg pointer-walks—snel en voorspelbaar. De top 8 suggesties voor elke mogelijke prefix zijn vooraf berekend. Slechtste geval? O(lengte van input). Niets bijzonders dus.

De rest: Alles andere staat op een SSD met een memory-mapped block index. Domeinen zijn gesorteerd, delta-compressed en georganiseerd in blokken van vaste grootte. Een kleine in-memory directory maakt binary search mogelijk. Die 240M domeinen nemen zo'n 2,5GB in beslag, en het besturingssysteem handelt caching van hot pages automatisch af.

Beide structuren hebben begrensde inputs—het aantal domeinen en de querylengte groeien niet eindeloos. Daardoor is de effectieve complexiteit praktisch O(1) en blijft p99-latentie consistent laag.

De cijfers

Load testing onthulde iets interessants. De API zelf beantwoordt de meeste verzoeken in minder dan 2ms. Zelfs onder belasting van 1.600 requests per seconde, reageert Nginx plus de API in 15ms bij p99. Redelijk solide.

Maar dan komt de realiteit: het netwerk. In de praktijk is end-to-end latentie gelijk aan de round-trip tijd van browser via Cloudflare naar je server, plus zo'n 10ms overhead. Voor gebruikers in dezelfde regio als de server zit je binnen budget. Voor de rest? Daar komt de asterisk kijken.

De asterisk

p99 0ms* betekent dat 99% van de verzoeken resultaten teruggeeft vóórdat de gebruiker klaar is met typen—mits ze dicht bij de server zitten. Voeg 100-200ms transatlantische latentie toe, en je schiet plotseling over budget.

De oplossing zouden geo-gedistribueerde servers met load balancing zijn. Maar voor een side project is dat veel infrastructuur om te onderhouden. Soms is "goed genoeg" echt goed genoeg—zeker wanneer je doelgroep Europese developers zijn die domeinen checken.

Lessen voor je volgende project

Deze les gaat verder dan domeinlookups: prefetch slim. Als je weet wat gebruikers waarschijnlijk als volgende vragen, haal het op voordat ze erom vragen. Laat de interface reageren op wat klaarstaat in plaats van te wachten op zekerheid.

De tweede les gaat over datastructuren. Een trie voor hot data, een goed geïndexeerde gesorteerde structuur voor de rest. Je hoeft echt niet 240 miljoen items in RAM te houden als je toegangspatronen ontwerpt rond wat daadwerkelijk waarschijnlijk wordt opgevraagd.

Tot slot: meet je werkelijke budget. In dit geval waren het twee toetsaanslagen plus een pauze. Wat is jouw equivalent? Vind het, optimaliseer ervoor, en stop met optimaliseren daarna.

Het resultaat voelt als magie. Maar het begint met precies begrijpen hoeveel tijd je daadwerkelijk hebt.

Read in other languages:

RU BG EL CS UZ TR SV FI RO PT PL NB HU IT FR ES DE DA ZH-HANS EN