Où passent les millisecondes d'une recherche

En bref

• Le budget utile d'une recherche qui répond pendant la frappe, ce sont les 100 ms qu'une personne lit comme une réponse immédiate, et le serveur ne peut en dépenser qu'une partie.
• Sur une mesure en production, la médiane du côté du serveur s'est établie à 24 ms, et le moteur de recherche a représenté moins d'un tiers de ce total.
• Ce qui fait la différence n'est pas un cache : c'est de ne pas faire de travail inutile à chaque touche.
• Un cache de résultats rapporte moins qu'on ne le pense, parce que les recherches d'une boutique ont une longue traîne et que le stock change.
• Le temps que ressent le visiteur inclut le réseau et le dessin dans le navigateur, et cette partie se perd plus vite qu'on ne la gagne du côté du serveur.

Promettre une « recherche instantanée » est facile, et nous le promettons aussi. Ce qui compte, c'est le budget derrière la promesse : combien de millisecondes existent, à quoi elles sont dépensées, et ce que l'on décide de ne pas faire pour ne pas les dépenser. Cet article est cette comptabilité, sans marketing.

Le budget n'est pas un choix de notre part. Il vient d'une limite connue depuis 1993, quand Jakob Nielsen a fixé les trois limites du temps de réponse : 0,1 seconde est la limite pour qu'une personne sente que le système réagit instantanément. Une recherche qui répond pendant la frappe doit tenir là-dedans, et le serveur n'est pas le seul convive à table : le réseau et le dessin dans le navigateur veulent aussi leur part.

Ce que nous avons mesuré, et dans quelles conditions

Les chiffres qui suivent ne viennent pas d'un test synthétique. Ils ont été relevés sur un serveur de production le 9 août 2026, avec 84 requêtes de recherche vers une boutique PrestaShop à nous, et ils viennent de l'en-tête Server-Timing que le service envoie sur toutes les requêtes, sans porte d'accès.

Avant de les lire, trois réserves qui changent l'interprétation :

• Le catalogue était petit, avec 19 produits. C'est la part du moteur de recherche qui grandit le plus avec la taille de l'index ; les autres ne bougent presque pas.
• Le serveur était sans charge, avec une charge moyenne inférieure à 0,2 sur quatre cœurs. Ces chiffres sont un plancher, pas une promesse aux heures de pointe.
• Les marques mesurent le temps d'horloge de chaque opération, et beaucoup tournent en parallèle exprès. C'est pourquoi la somme des tranches est plus grande que le total, et cela se lit ainsi : une grande tranche dit combien de temps on a attendu cette opération, pas de combien elle a retardé la réponse.

Le chemin d'une touche jusqu'à la réponse

Chaque touche tapée dans le champ déclenche le même parcours :

1. Le layer dans la boutique attend un court instant pour ne pas envoyer une requête par lettre, et il regroupe ce qui a été écrit entre-temps.
2. La requête arrive à notre service, qui identifie la boutique par la clé publique et choisit le bon index (boutique, langue et devise).
3. La requête est préparée : normalisation du texte, synonymes de la boutique, règles de merchandising actives, filtres déjà choisis.
4. Le moteur de recherche répond avec des produits, des comptes par facette et des mises en évidence.
5. La réponse est assemblée avec les champs dont ce dessin de résultats a besoin, et aucun autre.

Aucune de ces étapes n'est optionnelle ni surprenante. Le temps se gagne à l'intérieur de chacune.

Où passent les millisecondes

Deux lignes méritent une explication, et ce sont les deux qui surprennent.

Celle de l'enregistrement pour l'analytics est celle qui abîme d'habitude ce genre de systèmes. Enregistrer la recherche avant de répondre ajoute une écriture au chemin critique, et une base de données qui passe une mauvaise minute devient une recherche qui passe une mauvaise minute pour tout le monde. Ces 2,5 ms existent, ils sont réels, et ils ne sont pas payés par le visiteur : l'écriture part une fois que la réponse est déjà partie. C'est l'exemple le plus clair de cette réserve sur les tranches en parallèle.

Celle de la seconde tentative est la part que le plus de monde ne s'attend pas à trouver. Quand la première recherche allait finir sur peu ou rien, on en lance une autre, plus tolérante, pour ne pas renvoyer un écran vide à quelqu'un qui a échangé une lettre. Elle coûte presque autant que la recherche principale, et c'est de l'argent bien dépensé : l'écran sans résultat coûte cher d'une autre manière.

Remarquez ce que le tableau ne montre pas : aucune étape ne domine. Il n'y a pas de goulot d'étranglement à attaquer, et c'est pour cela que la seule façon de descendre plus bas est d'enlever du travail, pas d'optimiser un endroit.

Pour et contre un cache de résultats

La question revient toujours : pourquoi ne pas garder les réponses les plus demandées ? Nous gardons certaines choses, mais pas les résultats de recherche, et le raisonnement mérite d'être expliqué.

La troisième ligne de la colonne de gauche est la plus dangereuse, parce qu'un cache améliore les moyennes sans améliorer l'expérience de celui qui a écrit une chose rare, c'est-à-dire précisément celui qui a le plus besoin d'une bonne recherche.

Ce que nous faisons à la place, c'est garder en mémoire ce qui change peu (configuration de la boutique, synonymes, règles) et ne pas répéter le travail à chaque requête. Le gain est comparable et il n'y a rien à invalider.

Ce que le visiteur ressent

Ces 24 ms sont notre part, et c'est la plus facile des trois. Ce que la personne ressent en inclut deux de plus :

• Le réseau. Une requête depuis un téléphone en réseau mobile passe facilement plus de temps à voyager que nous à répondre. C'est pour cela que les requêtes sont petites et que la réponse n'apporte que les champs de la carte produit. Du côté de la boutique il n'y a aucun travail à ajouter : le module pour PrestaShop injecte une seule balise de script et le traitement se passe hors du serveur de la boutique.
• Le dessin dans le navigateur. Une grille avec de grandes images peut passer plus de temps à se composer que tout le reste réuni. Des images avec une taille déclarée et un chargement différé valent plus que n'importe quelle optimisation de notre part du côté du serveur.

C'est pourquoi la seule mesure que nous respectons est celle qui inclut les trois parties. Une jolie médiane de serveur avec une boutique lente reste une boutique lente.

Ce que nous avons décidé de ne pas faire

• Nous ne lançons pas une requête à chaque touche sans attendre : le court intervalle épargne la majorité des requêtes et personne ne le sent.
• Nous ne renvoyons pas le produit entier. La carte a besoin de sept champs et c'est cela qui voyage.
• Nous n'écrivons pas l'analytics sur le chemin critique.
• Nous ne gardons pas les résultats en cache, pour les raisons ci-dessus.
• Nous ne précalculons pas de facettes pour des combinaisons que personne n'a demandées.

Aucune de ces décisions n'est spectaculaire. Additionnées, elles font la différence entre une recherche qui répond pendant la frappe et une qui répond quand on a fini d'écrire.

Questions fréquentes

Combien de temps doit prendre la recherche d'une boutique en ligne ?

En dessous de 100 ms du clavier jusqu'à l'écran est l'objectif raisonnable pour une recherche qui répond pendant la frappe, parce que c'est là que la réponse cesse d'être ressentie comme une attente. Sur une mesure en production avec 84 requêtes, notre médiane du côté du serveur s'est établie à 24 ms, dont moins de 7 ms pour le moteur de recherche. Le reste du budget appartient au réseau et au navigateur, et c'est là que presque toutes les boutiques le perdent.

Un cache de résultats rend-il la recherche plus rapide ?

Il améliore les moyennes et guère plus. Les recherches d'une boutique ont une très longue traîne, les prix et le stock changent au cours de la journée, et les filtres multiplient les combinaisons à garder. Le travail d'invalidation du cache est en général plus grand que le gain.

Qu'est-ce qui rend une recherche lente ?

Des index avec trop de champs interrogeables, des facettes avec des milliers de valeurs, des écritures d'analytics sur le chemin de la réponse, et des réponses qui apportent le produit entier alors que la carte n'utilise qu'une poignée de champs.

La recherche rend-elle la boutique plus lente ?

Elle ne devrait pas. Le traitement se passe hors du serveur de la boutique et la réponse est petite. Ce qui pèse d'habitude sur la page, c'est le dessin des résultats : des images sans taille déclarée et sans chargement différé coûtent plus cher que toute la recherche.

Mesurez-vous le temps du côté du serveur ou du côté du visiteur ?

Les deux. Le temps de serveur est celui que nous pouvons optimiser directement, et il part dans toutes les réponses dans l'en-tête Server-Timing, découpé par étape et sans porte d'accès : qui veut confirmer les chiffres de cet article ouvre les outils du navigateur sur une boutique où Buskara est installé. Le temps du visiteur inclut le réseau et le dessin dans le navigateur, et c'est le seul qui corresponde à ce que la personne ressent.

Les chiffres de cet article valent-ils pour mon catalogue ?

La part du moteur de recherche, pas forcément : elle a été mesurée sur un catalogue de 19 produits et c'est la part qui grandit le plus avec la taille de l'index. Les autres parts (identifier la boutique, choisir l'index, appliquer les règles, compter les facettes) dépendent peu du nombre de produits et beaucoup de la configuration. La forme du tableau reste la même ; c'est la première ligne qui change.