Il y a un an, nous avons livré un site vitrine à fort trafic avec Gatsby en frontend et WordPress comme back-office de contenu. L’objectif : profiter de la vitesse d’un site entièrement statique tout en laissant les rédacteurs travailler dans une interface qu’ils connaissent déjà. Un an de recul plus tard, le bilan mérite d’être partagé sans filtre, avec ses réussites et ses irritants.
Gatsby s’est imposé depuis 2018 comme l’un des générateurs de sites statiques les plus populaires de l’écosystème React, porté par son approche « tout en GraphQL » et son vaste catalogue de plugins de source de données. Coupler Gatsby à WordPress via le plugin gatsby-source-wordpress était, sur le papier, une évidence pour ce projet éditorial à fort volume de trafic mais à fréquence de publication modérée.
L’architecture mise en place
Le principe : au moment du build, gatsby-source-wordpress interroge l’API WordPress (à l’époque, la version du plugin s’appuyait sur WPGraphQL plutôt que sur l’API REST native) et rapatrie l’intégralité du contenu dans le cache GraphQL interne de Gatsby. Chaque page du site est ensuite générée en HTML statique, prêt à être déployé sur un CDN.
// gatsby-config.js
module.exports = {
plugins: [
{
resolve: `gatsby-source-wordpress`,
options: {
url: `https://exemple.fr/graphql`,
schema: {
perPage: 20,
},
},
},
],
};Les pages sont ensuite créées dynamiquement dans gatsby-node.js, en itérant sur les articles récupérés via une requête GraphQL exécutée au build :
exports.createPages = async ( { graphql, actions } ) => {
const { createPage } = actions;
const resultat = await graphql(`
{
allWpPost {
nodes { slug id }
}
}
`);
resultat.data.allWpPost.nodes.forEach( ( article ) => {
createPage( {
path: `/articles/${ article.slug }/`,
component: require.resolve( './src/templates/article.js' ),
context: { id: article.id },
} );
} );
};Ce qui a bien fonctionné
Les résultats sur les indicateurs de performance ont dépassé nos attentes. Un site entièrement statique, servi depuis un CDN, sans base de données à interroger à chaque visite : les temps de chargement se sont effondrés par rapport à l’ancien WordPress classique, même correctement mis en cache. Le score Lighthouse est passé d’une moyenne de 65 à plus de 95 sur les pages principales.
Le SEO a suivi la même tendance : Google indexe du HTML pur, sans dépendre d’un rendu JavaScript côté client, ce qui a éliminé les inquiétudes qu’un projet React classique aurait pu soulever sur ce terrain.
Ce qui a posé problème
Le premier irritant est arrivé progressivement : le temps de build. Au lancement, avec environ 200 articles, un build complet prenait un peu moins de deux minutes. Un an plus tard, avec plus de 1 200 contenus publiés, ce même build dépasse les douze minutes. Ce n’est pas rédhibitoire, mais cela change concrètement le rythme de travail : chaque publication d’article impose d’attendre la fin du build avant que le contenu n’apparaisse en ligne.
Le deuxième point, plus gênant pour l’équipe éditoriale, concerne la prévisualisation des brouillons. Par nature, un site généré statiquement au build ne peut pas refléter en temps réel un brouillon enregistré dans WordPress. Les rédacteurs, habitués au bouton « Aperçu » classique, ont dû changer leurs habitudes et attendre un rebuild pour voir leur contenu réellement rendu, ce qui a fortement ralenti les cycles de relecture.
- Temps de build qui grandit linéairement avec le volume de contenu
- Aucune prévisualisation instantanée des brouillons pour les rédacteurs
- Chaque publication ou correction nécessite un redéploiement complet du site
- Courbe d’apprentissage GraphQL non négligeable pour une équipe habituée à du PHP classique
Comment nous avons limité la casse
Pour le temps de build, nous avons mis en place un déclenchement automatique via un webhook WordPress sur l’action save_post, qui appelle un service de build continu plutôt que d’attendre un déploiement manuel. Cela ne réduit pas la durée du build lui-même, mais supprime l’intervention humaine dans la boucle.
Pour la prévisualisation, nous avons finalement mis en place un environnement de préproduction séparé, rebuild plus fréquemment, sur lequel les rédacteurs peuvent consulter un rendu proche du réel avant publication définitive. Ce n’est pas un aperçu instantané, mais un compromis acceptable.
Un site statique généré au build est un excellent choix pour un contenu qui bouge peu et un trafic qui compte beaucoup. Ce n’est clairement pas la bonne architecture pour une rédaction qui publie et corrige plusieurs fois par jour et attend un retour immédiat.
Notre verdict
Un an après le lancement, le bilan reste positif sur les critères de performance et de SEO, mais le compromis sur l’expérience éditoriale est réel et doit être anticipé dès le cahier des charges, pas découvert en cours de route. Gatsby et WordPress forment un duo solide pour un site à fort trafic et à publication modérée : un blog institutionnel, un site vitrine, une documentation. Pour une rédaction qui publie en continu et attend une prévisualisation immédiate, d’autres approches, combinant génération incrémentale ou rendu à la demande, méritent d’être envisagées en priorité.
