Principe de préchargement côté client

Le mécanisme repose sur deux événements clavier. Lors du keyDown, le client interroge l'API pour le préfixe composé du caractère tapé et du caractère suivant. Lors du keyUp, les suggestions déjà reçues sont affichées. Cette séquence crée une fenêtre temporelle égale à la durée du premier appui, l’intervalle entre deux frappes et la durée du second appui. L’auteur a mesuré un p99 de 121 ms pour ce budget sur son propre clavier, ce qui signifie que 99 % du temps les réponses doivent arriver avant le relâchement de la touche.

document.addEventListener('keydown', e => {
  prefetchSuggestions(e.key + nextChar);
});

document.addEventListener('keyup', e => {
  renderSuggestions();
});

Architecture de l'API : trie en mémoire et index SSD

L’API exploite deux structures distinctes. La « head » utilise un trie en mémoire contenant les 8 meilleures suggestions pour chaque préfixe issu du classement Tranco (1 M de domaines). La recherche se résume à un parcours de pointeurs, avec une complexité O(L) où L est la longueur du préfixe, pratiquement constante pour les noms de domaine.

La « tail » gère les 240 M de domaines fournis par CZDS. Les noms sont triés, delta‑compressés et stockés en blocs fixes de 256 entrées. Un répertoire en mémoire de 27 MB permet de localiser le bloc via une recherche binaire, puis de scanner linéairement le bloc. La complexité théorique est O(L·log(N)), mais N étant limité par la taille du répertoire, le temps d’accès se comporte également comme O(1). L’ensemble occupe 2,5 GB sur SSD, les pages chaudes étant mises en cache par le système d’exploitation.

Mesures de performance et limites

Un test de charge généré par un LLM a simulé 720 000 frappes, soit 60 000 noms de domaine, à un débit constant. En isolation, l’API répond en 2 ms en moyenne. Sous Nginx, à 1,6 k requêtes/s, le temps de réponse reste 15 ms pour 99 % des requêtes. Le facteur dominant devient alors le round‑trip réseau (navigateur → Cloudflare → serveur), estimé à ≈10 ms plus la latence du réseau. Ainsi, le budget de 121 ms est largement respecté même avec 1 000 utilisateurs simultanés.

La principale contrainte reste la distance géographique. Depuis les États‑Unis, le RTT ajoute 100‑200 ms, dépassant le seuil p99. Le déploiement de serveurs géo‑répartis ou le cache CDN des chemins chauds pourrait ramener la latence à 0 ms* p99, mais le coût opérationnel est jugé disproportionné pour un service de niche.