Nuxt SSG vs SSR pour une vitrine : `nuxt generate` (preset Nitro `static`) produit des fichiers. Le SSR calcule à chaque requête (ou avec cache). Pour un site marketing de 15 à 40 pages, le statique gagne presque toujours : perf, sécu, coût, TMA. Cet article départage, lie « WordPress ou site statique », et dit quand le SSR (ou l'hybride) vaut un serveur Node en prod. MakeDigital lui-même est en SSG.
📄 SSG : le défaut honnête d'une vitrine
Build, fichiers, CDN. Pas de PHP, pas de Node exposé. Les pages bougent quand on régénère le site. Pour une TMA de vitrine, c'est du calme. Le SEO voit du HTML complet. Les Core Web Vitals aiment.
Limite : une prévisualisation en temps réel, des produits qui changent toutes les heures. Là on discute SSR, ISR, ou on revient à un CMS.
⚙️ SSR : quand ça vaut Node
Contenu par utilisateur, personnalisation, données fraîches à chaque requête, preview headless exigeant. Coût : process, cache, TMA front, incidents 502.
Une vitrine « on veut être modernes » n'est pas un critère. Une app oui.
- Rythme de publication
- Pages privées ?
- Équipe pour tenir Node
- Budget TMA front
🔗 Avec WordPress
Headless + SSG : rebuild au webhook. Headless + SSR : plus cher. Voir les articles WordPress classique vs headless et le coût d'un headless.
Nuxt SSG vs SSR pour une vitrine : je commence statique. J'ajoute du serveur si le métier le force.
🧩 Le formulaire et les parties dynamiques
Un site statique n'est pas un site sans interaction. Le formulaire de contact envoie vers une API ou un service d'envoi, la recherche peut tourner dans le navigateur, un avis client se charge après la page.
Je liste ces besoins avant de choisir. S'il y en a deux ou trois, le statique les absorbe sans serveur. S'il y en a partout, et propres à chaque visiteur, c'est le signe qu'il faut du SSR.
✅ Liste de contrôle avant la bascule statique
Avant la bascule, j'écris quelles pages changent souvent, lesquelles dépendent du visiteur et lesquelles peuvent être générées une fois. La mesure qui compte : le temps d'affichage réel sur mobile et la présence de chaque URL dans le sitemap.
Sauvegarde du site actuel, liste des URLs à conserver, accès au domaine à votre nom. Puis la génération statique. Puis 24 à 72 h de surveillance (erreurs 404, Search Console, formulaires). Sans ces vérifications, on a changé de technique, pas démontré que rien n'a cassé.
- Temps d'affichage mobile relevé sur les pages principales
- Prévisualisation sur adresse provisoire avant la bascule
- Un changement à la fois, documenté
- Comparaison des URLs générées avec l'ancien sitemap, puis suivi des erreurs 404 sur une semaine
📌 Ce que je refuse sur ce sujet
Je refuse de monter un serveur de rendu pour un site vitrine qui change une fois par mois. Je refuse aussi la génération statique quand le contenu doit être à jour à la minute près : on déplace le problème au lieu de le régler.
Si votre site actuel est rapide et bien référencé, changer de mode de rendu n'apporte rien : je préfère vous le dire que refaire le site pour rien.
Une vitrine n'a pas besoin d'un serveur à chaque visite. Elle a besoin d'un HTML tenu.
🧭 Questions fréquentes
Faut-il migrer maintenant ? Seulement si le serveur coûte cher pour un contenu qui ne bouge pas, ou si les pages sont lentes à cause du rendu à chaque visite. Sinon, c'est un chantier qu'on place dans la prochaine évolution du site.
Peut-on passer en statique sans prévisualisation ? Rarement : on génère le site en entier, on vérifie les pages clés sur une adresse provisoire, puis on bascule le domaine. Les hébergeurs statiques proposent tous une adresse de prévisualisation par version.
Combien de temps ? Souvent de deux jours pour une vitrine de dix pages à deux semaines si le contenu vient d'un CMS et qu'il faut déclencher la reconstruction à chaque modification. Un devis sans ce détail est incomplet.
