Un client nous a posé la question la semaine dernière, presque mot pour mot : « Vous faites du Vue.js, très bien, mais lequel de vos outils convient à un blog WordPress d’une centaine d’articles ? » La question paraît anodine, elle ne l’est pas. Début 2020, deux générateurs se partagent l’attention de la communauté Vue.js pour consommer l’API REST de WordPress sans thème PHP classique : Nuxt.js, utilisé en mode generate, et Gridsome, plus jeune, pensé dès l’origine pour le contenu statique.
Nuxt 3 n’existe pas encore, il ne sera annoncé que bien plus tard. On travaille donc avec Nuxt 2, son mode universel et son mode de génération statique encore jeune. Face à lui, Gridsome copie ouvertement l’approche de Gatsby côté React, avec une couche GraphQL qui unifie toutes les sources de données. Le comparatif qui suit part de deux projets réels menés ces derniers mois à l’agence, l’un en Nuxt, l’autre en Gridsome, sur des cahiers des charges comparables.
Deux philosophies, un même écosystème Vue.js
Nuxt.js a été pensé comme un framework applicatif complet : rendu serveur, routes dynamiques, middleware, et depuis peu un mode nuxt generate qui produit des pages HTML statiques à partir de ces mêmes routes. WordPress n’est qu’une source de données parmi d’autres, interrogée via axios ou le module @nuxtjs/axios, en tapant directement dans les points de terminaison /wp-json/wp/v2/posts.
Gridsome, lui, part du principe inverse : le site est statique par construction, et toutes les sources externes (WordPress, Markdown, API tierces) sont importées dans un unique graphe GraphQL local au moment du build, via le plugin officiel gridsome-source-wordpress. On ne requête plus jamais l’API REST à l’exécution : tout est aplati dans un fichier de données consommé par les composants Vue au build.
Nuxt en mode generate face à l’API REST de WordPress
Sur le projet Nuxt, chaque page dynamique déclare une méthode asyncData qui va chercher ses données via l’API REST :
export default {
async asyncData({ params, $axios }) {
const post = await $axios.$get(
`https://api.exemple.fr/wp-json/wp/v2/posts?slug=${params.slug}`
)
return { article: post[0] }
}
}
Le mode generate a besoin de connaître à l’avance la liste de toutes les routes dynamiques, via la clé generate.routes de nuxt.config.js. Cela oblige à faire un premier appel réseau juste pour lister les slugs avant de lancer le build proprement dit, une étape que Gridsome gère différemment.
Gridsome et son GraphQL interne : la couche qui change tout
Avec Gridsome, la configuration de la source WordPress se fait une fois pour toutes dans gridsome.config.js, et le plugin se charge de parcourir automatiquement toutes les collections de l’API REST (articles, pages, types personnalisés exposés). Les composants n’interrogent plus jamais un point de terminaison, ils écrivent des requêtes GraphQL locales, résolues au build :
query Post ($id: ID!) {
post: wordPressPost(id: $id) {
title
content
date
}
}
L’avantage est net sur la cohérence des données : impossible d’oublier un appel réseau ou de désynchroniser deux composants qui liraient la même donnée différemment. L’inconvénient, découvert sur notre projet, c’est la marge de manœuvre plus réduite dès qu’on sort du cas standard « articles et pages » : un type personnalisé mal exposé côté REST demande de patcher le plugin source, pas seulement le composant front.
Le temps de build, l’angle mort des deux solutions en 2020
Sur un site de deux cents articles, le build Gridsome prend un peu plus de quatre minutes chez nous, contre un peu moins de trois minutes pour l’équivalent Nuxt generate. La différence s’explique par la phase d’indexation GraphQL de Gridsome, qui reconstruit l’intégralité du graphe à chaque build, même pour une modification mineure. Aucun des deux outils ne propose, à ce stade, de reconstruction incrémentale : c’est un point faible commun qu’il faudra garder à l’œil à mesure que les sites grossissent.
Ce que cela change concrètement pour un client
- Un blog de moins de cinquante pages : la différence de build est négligeable, le choix se fait sur d’autres critères.
- Un site catalogue avec plusieurs types de contenu personnalisés : Gridsome impose une discipline de nommage plus stricte côté API REST.
- Une équipe qui connaît déjà Gatsby : Gridsome sera nettement plus rapide à prendre en main.
Écosystème de plugins et communauté : où chercher de l’aide
Nuxt bénéficie d’une communauté nettement plus large, portée par Vue.js dans son ensemble et par des modules officiels nombreux (@nuxtjs/sitemap, @nuxtjs/pwa…). Gridsome, plus jeune, a une communauté plus restreinte mais très active sur les problématiques headless spécifiquement, ce qui se ressent dans la qualité de sa documentation dédiée aux sources de données externes.
| Critère | Nuxt.js (mode generate) | Gridsome |
|---|---|---|
| Approche des données | Appels REST à la demande | Graphe GraphQL unifié au build |
| Courbe d’apprentissage | Modérée si on connaît Vue.js | Rapide si on connaît Gatsby |
| Types personnalisés WordPress | Flexible, code au cas par cas | Discipline requise côté REST |
| Écosystème de modules | Très large | Restreint mais ciblé headless |
| Temps de build (200 articles) | ~3 min | ~4 min |
Chez nous, la règle est simple : si le client a déjà un backend WordPress avec des types de contenu personnalisés bien exposés en REST, Gridsome accélère franchement la mise en place. Sinon, Nuxt garde plus de portes ouvertes pour bricoler.
Notre verdict
Pour un site éditorial classique, articles et pages, sans structure de données trop exotique, Gridsome nous a fait gagner du temps sur ce projet : la couche GraphQL évite bien des allers-retours de débogage réseau. Pour un projet plus atypique, avec des besoins d’authentification ou des pages qui ne se prêtent pas à la génération statique pure, Nuxt reste le choix le plus sûr aujourd’hui, quitte à perdre un peu en confort de développement. Aucun des deux ne s’impose universellement : c’est la nature du contenu WordPress à consommer qui doit trancher, pas la préférence personnelle pour telle ou telle syntaxe.
