Un site catalogue de pièces détachées industrielles, avec plus de 10 000 fiches produits, devait passer d’un rendu dynamique classique à une génération statique complète via Next.js, pour des raisons de performance et de résilience face aux pics de trafic. La question technique posée en amont a divisé l’équipe : fallait-il continuer à consommer l’API REST WordPress déjà en place, ou migrer vers WPGraphQL pour ce projet précis ?
Plutôt que de trancher sur des arguments théoriques, le choix a été de mesurer, sur ce catalogue réel et avec les mêmes données, le temps de build complet des deux approches, dans des conditions strictement identiques : même machine de build, même environnement WordPress, même nombre de pages générées.
Le protocole de mesure
Deux versions du script de génération ont été écrites en parallèle. La première interroge l’API REST classique via l’endpoint /wp/v2/produit avec le paramètre _embed pour récupérer en une seule requête les données liées (catégorie, image mise en avant, marque). La seconde interroge un unique endpoint WPGraphQL, avec une requête ciblée ne demandant que les champs réellement utilisés dans le gabarit de page produit.
query ListeProduits($apres: String) {
produits(first: 100, after: $apres) {
pageInfo { hasNextPage endCursor }
nodes {
slug
titre
prixHT
categorie { nom }
imageMiseEnAvant { sourceUrl(size: MEDIUM) }
}
}
}Les deux scripts ont été exécutés cinq fois chacun, à des heures différentes de la journée pour lisser l’effet du cache serveur, sur la même infrastructure de build en intégration continue.
Les chiffres obtenus
| Étape | API REST (avec _embed) | WPGraphQL (requête ciblée) |
|---|---|---|
| Récupération de la liste des 10 000 produits | 6 min 40 s (102 requêtes paginées) | 3 min 55 s (100 requêtes paginées) |
| Volume de données transféré | 184 Mo | 61 Mo |
| Génération des pages statiques | 11 min 10 s | 10 min 50 s |
| Temps de build total | 17 min 50 s | 14 min 45 s |
L’écart mesuré sur le temps de build total avoisine 17 %, mais grimpe à plus de 35 % sur la seule étape de récupération des données, celle où la différence entre les deux approches se joue réellement. La génération des pages statiques proprement dite, elle, ne varie presque pas : une fois les données en mémoire, le moteur de rendu de Next.js met le même temps à produire le HTML, quelle que soit la source de la donnée.
D’où vient l’écart
Le paramètre _embed de l’API REST, bien que pratique pour éviter des requêtes en cascade, renvoie systématiquement l’intégralité des champs de chaque ressource liée : l’objet catégorie complet avec sa description, ses métadonnées SEO, ses liens de navigation, alors que le gabarit de page produit n’affichait que le nom de la catégorie. Ce sur-fetching, invisible sur une seule fiche produit, se multiplie par 10 000 sur l’ensemble du catalogue et explique l’essentiel du volume de données transféré en trop.
WPGraphQL, en ne demandant explicitement que les champs utilisés (nom pour la catégorie, une seule taille d’image plutôt que toutes les tailles générées par WordPress), réduit mécaniquement ce volume, sans changer la charge réelle sur la base de données, qui reste comparable entre les deux approches.
Un point à ne pas généraliser trop vite
Il serait tentant de conclure que WPGraphQL est systématiquement plus rapide qu’une API REST bien utilisée. Ce n’est pas ce que ce test démontre. Le test compare une API REST utilisée de façon peu optimisée (avec _embed par défaut) à une requête WPGraphQL délibérément ciblée. Une API REST utilisant le paramètre _fields pour ne demander que les champs nécessaires, combinée à un appel séparé et mis en cache pour les catégories, aurait probablement réduit une grande partie de cet écart sans changer de technologie.
Le choix final sur ce projet
L’équipe a opté pour WPGraphQL sur ce catalogue précis, non pas uniquement pour le gain de temps de build mesuré, mais parce que la syntaxe de requête ciblée rendait plus difficile, structurellement, de retomber dans le piège du sur-fetching à l’avenir, à mesure que de nouveaux champs seraient ajoutés au catalogue par d’autres développeurs de l’équipe.
- Un gain de temps de build réel mais modéré (environ 3 minutes sur ce projet), significatif uniquement parce que le build s’exécute plusieurs fois par jour en intégration continue.
- Une réduction du volume de données transférées qui limite les coûts de bande passante facturés par certains hébergeurs d’API.
- Un contrat de requête explicite, plus facile à auditer en revue de code qu’un paramètre
_embeddont le contenu exact dépend de la configuration WordPress du moment.
Le sur-fetching ne se voit jamais sur une seule requête ; il se voit uniquement quand on le multiplie par le volume réel du projet, ce qui rend les tests sur un jeu de données restreint souvent trompeurs.
En résumé
Sur un catalogue de 10 000 pages, la différence de temps de build entre API REST et WPGraphQL existe bel et bien, mais elle tient moins à la technologie elle-même qu’à la discipline de ne demander que les champs réellement nécessaires. WPGraphQL rend cette discipline plus naturelle à adopter et à maintenir dans le temps, ce qui explique le choix final davantage que le seul chiffre de gain mesuré lors de ce test ponctuel.
