Trois appels réseau, exécutés l’un après l’autre, avant même le premier octet envoyé au navigateur : c’est ce que montrait le graphe de traces d’un plugin de recommandation de produits par intelligence artificielle, installé sur une fiche produit pour suggérer des articles complémentaires. Chaque appel prenait entre 250 et 400 millisecondes, et le troisième ne commençait qu’une fois le deuxième terminé.
Ce qu’on observe
Le plugin, une fois activé, interrogeait successivement un service de scoring de similarité produit, un service de personnalisation basé sur l’historique de navigation, et un service de disponibilité de stock en temps réel, chacun hébergé chez un prestataire différent. Le code appelait ces trois services de façon strictement séquentielle, chaque requête wp_remote_get() attendant la réponse de la précédente avant de démarrer :
// Ce qu'on trouvait dans le plugin
$scoring = wp_remote_get( $url_scoring );
$personnalise = wp_remote_get( $url_personnalisation );
$disponibilite = wp_remote_get( $url_stock );
// Trois appels, un seul après l'autre : 250 + 300 + 400 ms cumulésLe rendu de la page attendait la résolution complète des trois appels avant de générer le HTML final, y compris pour les visiteurs qui ne faisaient jamais défiler jusqu’au bloc de recommandations situé en bas de fiche produit.
Pourquoi c’est un problème pour le TTFB
Le TTFB (Time To First Byte) mesure le temps avant que le navigateur ne reçoive le premier octet de la réponse HTML. Tant que le serveur PHP reste bloqué à attendre une réponse réseau, aucun octet ne peut être envoyé, même si le contenu principal de la page (titre, prix, description) est déjà entièrement disponible en mémoire depuis longtemps. Sur ce site, le TTFB des fiches produits concernées atteignait 1 600 ms en moyenne, contre 500 ms sur les fiches sans le module de recommandation, un écart directement imputable à cette cascade d’appels bloquants exécutés avant l’affichage.
- Chaque appel séquentiel ajoute son temps de latence complet au temps de réponse total du serveur.
- Une panne ou une lenteur chez un seul des trois prestataires ralentit l’intégralité de la fiche produit, pas seulement le bloc de recommandations.
- Le contenu principal de la page, pourtant indépendant des recommandations, reste bloqué derrière ces appels sans raison fonctionnelle.
Comment paralléliser les appels
La première correction a consisté à remplacer les trois appels séquentiels par des requêtes non bloquantes lancées en parallèle, grâce aux arguments blocking de l’API HTTP de WordPress combinés à curl_multi via une bibliothèque de requêtes concurrentes, ou plus simplement en utilisant le support natif de traitement par lots que certains SDK de ces prestataires exposent déjà :
$requetes = array(
'scoring' => array( 'url' => $url_scoring ),
'personnalise' => array( 'url' => $url_personnalisation ),
'disponibilite' => array( 'url' => $url_stock ),
);
$reponses = reseau_executer_requetes_paralleles( $requetes );
// Les trois appels partent en même temps : temps total proche de 400 ms,
// et non plus la somme des troisSur ce site, ce seul changement a fait passer le temps cumulé des trois appels de 950 ms à environ 400 ms, le temps du plus lent des trois services, et non plus la somme de tous.
Comment différer ce qui peut l’être
La seconde correction, plus radicale, a consisté à sortir entièrement le bloc de recommandations du rendu initial de la page. Le HTML de la fiche produit s’affiche désormais immédiatement avec un conteneur vide pour les recommandations, rempli ensuite par un appel JavaScript asynchrone une fois la page chargée, via l’API REST WordPress exposée spécifiquement pour ce module.
Une recommandation personnalisée n’a jamais besoin d’être présente au premier octet. Elle peut arriver une demi-seconde plus tard sans que le visiteur ne le remarque, contrairement au prix ou au bouton d’ajout au panier.
Résultat sur le TTFB et l’expérience perçue
| Configuration | TTFB moyen | Recommandations affichées |
|---|---|---|
| Appels séquentiels, rendu bloquant | 1 600 ms | Immédiat mais tout est ralenti |
| Appels parallélisés, rendu bloquant | 950 ms | Immédiat, moins ralenti |
| Appels parallélisés, rendu différé en JS | 510 ms | Léger décalage, imperceptible |
Ce qui compte
La pertinence des recommandations n’a pas changé d’un octet dans cette intervention : le moteur de scoring, la personnalisation et le stock en temps réel continuent de fonctionner exactement comme avant. Ce qui a changé, c’est uniquement l’ordre et le moment où ces appels bloquent — ou non — le rendu de la page. Face à un module tiers qui multiplie les appels réseau, la première question à poser n’est jamais « est-ce pertinent ? » mais « est-ce que ça doit vraiment bloquer l’affichage ? ».
