Rendu côté serveur
Le rendu côté serveur (SSR) est la stratégie de rendu où le HTML d'une page est entièrement assemblé sur le serveur au moment de la requête et envoyé au navigateur sous forme de document complet. La première réponse contient déjà le texte, les liens et les balises meta, de sorte que la page a du sens avant même qu'un quelconque JavaScript ne s'exécute.
Le rendu côté serveur (SSR) est la stratégie de rendu où le HTML d'une page est entièrement assemblé sur le serveur au moment de la requête et envoyé au navigateur sous forme de document complet. La première réponse contient déjà le texte, les liens et les balises meta, de sorte que la page a du sens avant même qu'un quelconque JavaScript ne s'exécute.
Pourquoi c'est important
Les moteurs de recherche et les crawlers IA consacrent un budget réel à l'exécution du JavaScript. Googlebot utilise un modèle à deux passes, une analyse initiale du HTML, puis une passe de rendu JS différée, et livrer une coquille vide rendue côté client peut retarder ou ignorer entièrement l'indexation. Les crawlers IA comme GPTBot, PerplexityBot et ClaudeBot n'exécutent pour la plupart pas du tout le JS, ce qui signifie que le CSR est en pratique invisible pour les moteurs de réponse. Le SSR corrige cela d'un seul coup tout en améliorant les Core Web Vitals. C'est l'une des décisions techniques à plus fort effet de levier pour le SEO et le GEO.
CSR vs SSR vs SSG vs ISR
| Stratégie | Lieu de rendu | Premier HTML | Adéquation SEO | Cas d'usage |
|---|---|---|---|---|
| CSR (Client-Side Rendering) | Navigateur | Coquille vide | Faible | Tableaux de bord connectés |
| SSR (Server-Side Rendering) | Serveur, à chaque requête | Complet | Fort | Contenu dynamique et personnalisé |
| SSG (Static Site Generation) | Au build | Complet | Le plus fort | Blogs, docs, marketing |
| ISR (Incremental Static Regeneration) | Build + régénération périodique | Complet | Le plus fort | Pages statiques fréquemment mises à jour |
La priorité SEO est à peu près SSG ≈ ISR > SSR > CSR. Des frameworks comme Next.js, Nuxt, Remix et SvelteKit vous permettent de mélanger ces modes dans une seule base de code.
Implications pour le SEO et le GEO
Indexation immédiate : le contenu est visible dès la première passe de Googlebot, sans attendre la passe de rendu différée. L'indexation des nouvelles pages passe de quelques jours à quelques heures.
Compatibilité avec les crawlers IA : GPTBot et consorts n'exécutent pas le JS. Sans SSR, votre contenu n'existe en pratique pas pour l'entraînement et la recherche des LLM.
Amélioration des Core Web Vitals : le LCP se déclenche lorsque le premier HTML arrive, et non après le téléchargement et l'exécution d'un bundle JS. Le FCP, le LCP et le TTI s'améliorent tous.
Balises meta fiables : Open Graph, les extraits de recherche et les données structurées doivent figurer dans la première réponse pour être pris en compte. Le CSR envoie des balises meta vides à Twitter, Facebook et autres bots sociaux.
Amélioration progressive : le contenu reste accessible même avec le JS désactivé, sur des réseaux lents ou sur des appareils anciens.
Compromis du SSR
Coût serveur plus élevé : générer le HTML à chaque requête coûte du CPU, de la mémoire et de l'infrastructure. La mise en cache via CDN et l'ISR l'atténuent.
Augmentation possible du TTFB : une logique serveur lourde retarde le time-to-first-byte. Les requêtes en base et les API externes deviennent des goulots d'étranglement.
Complexité : les incohérences d'hydratation, les différences d'environnement serveur/client et l'invalidation du cache ajoutent tous un coût de débogage.
Limites de la personnalisation : un SSR par utilisateur est difficile à mettre en cache. Le schéma consiste en une coquille partagée et une personnalisation côté client.
L'hydratation et ses pièges
Une fois que le SSR a livré le HTML, le client l'« hydrate » en y rattachant le JavaScript pour le rendre interactif. Ce qui peut mal tourner :
Incohérence d'hydratation : lorsque le HTML rendu côté serveur et le premier rendu du client divergent, React/Vue émet des avertissements, souvent visibles sous forme de clignotement ou de comportement cassé.
Coût de l'hydratation : hydrater une grande page bloque le thread principal, ce qui dégrade l'INP. L'hydratation partielle, les React Server Components et les îlots Astro sont des alternatives.
SSR ≠ bundles plus petits : le SSR ne réduit pas le bundle client. Les deux nécessitent encore une optimisation.
Quand utiliser le SSR
- Le contenu dépend du trafic SEO/GEO (blogs, actualités, e-commerce, docs)
- Les données propres à l'utilisateur doivent figurer dans le premier rendu (tableaux de bord personnalisés)
- Les balises OG dynamiques comptent pour le partage social
- Vous visez les citations dans la recherche IA
Quand le SSR est superflu
- Tableaux de bord authentifiés (aucun enjeu SEO)
- Contenu statique, le SSG est plus rapide et moins cher
- Sites minuscules, un seul fichier HTML statique suffit
Erreurs fréquentes
Tout passer en SSR : le contenu statique est plus rapide et moins cher en SSG/ISR. Choisissez le bon mode par route.
Appeler des API sans mise en cache : récupérer des données à chaque requête sans cache fait exploser le TTFB. Utilisez SWR ou des en-têtes de cache.
Ignorer les incohérences d'hydratation : les avertissements de la console indiquent que le HTML vu par Google diffère de celui de l'utilisateur, un risque SEO.
Définir les balises meta uniquement côté client : les balises meta doivent exister dans le head de la réponse SSR pour que les bots puissent les lire.
Faire confiance aux réglages par défaut du framework : Next.js et Nuxt ne choisissent pas toujours le bon mode automatiquement. Définissez-le explicitement par route.
Sources :