SSR, CSR, SSG et ISR : la différence réelle
SSG génère le HTML avant la requête, généralement au build. SSR le génère sur le serveur pour chaque requête. CSR construit une grande partie de l'interface après exécution du JavaScript dans le navigateur. ISR conserve un résultat statique mais permet de régénérer certaines pages après déploiement. [6][9][16]
Les questions utiles sont donc : quand le HTML est-il créé, combien de temps est-il mis en cache et combien de travail reste au navigateur ?
SEO : Google rend JavaScript, mais CSR n'est pas équivalent au prerendering
Google décrit le traitement JavaScript en trois étapes : crawling, rendering et indexing. Si le HTML initial ne contient pas le contenu réel, le Web Rendering Service doit exécuter JavaScript et la page rejoint une file de rendu. [1]
Google indique également que SSR ou prerendering reste une bonne idée pour la vitesse des utilisateurs et des robots, et que tous les bots n'exécutent pas JavaScript. [1]
CSR peut donc fonctionner, mais du HTML déjà significatif est plus robuste pour le contenu public important.
SSG : excellent point de départ pour le contenu peu changeant
Avec SSG, le HTML est produit au build puis peut être servi comme fichier statique via CDN. Next.js recommande Static Generation lorsqu'une page peut être préparée avant la requête. [9][12]
Landing pages, documentation, articles, pages d'aide, portfolios et certaines listes de produits sont des cas typiques. [10][16]
La limite apparaît quand les données changent très souvent ou que le build devient trop long.
SSR : quand le contenu doit être frais ou dépendre de la requête
SSR génère le HTML pour une requête précise et peut utiliser données fraîches, headers, cookies, localisation ou paramètres. [6][10][11]
Le contenu arrive directement en HTML, mais chaque requête demande du travail serveur et un rendu lent peut augmenter le TTFB. [6]
Les parties stables peuvent néanmoins être mises en cache et seules les zones réellement dynamiques rester calculées à la requête.
ISR : HTML statique avec fraîcheur contrôlée
ISR conserve les avantages du HTML statique tout en permettant une régénération après déploiement. Next.js documente la mise à jour des pages statiques après build et Nuxt 4 propose des mécanismes similaires avec `isr` et `swr`. [9][13][16]
Cette stratégie convient aux catalogues, articles, documentation et catégories qui changent périodiquement sans exiger du temps réel.
Avec stale-while-revalidate, le premier visiteur après expiration peut recevoir l'ancienne version pendant la régénération. [13][16]
CSR : adapté aux applications qui n'ont pas besoin d'être indexées
En CSR, le navigateur doit télécharger, parser et exécuter JavaScript avant de construire une grande partie du DOM. web.dev explique que les gros bundles peuvent dégrader l'INP, surtout sur mobile. [6][7]
Nuxt cite les applications SaaS, back-office, jeux et interfaces très interactives sans exigence SEO comme cas adaptés. [13]
Pour le contenu public, CSR augmente la dépendance à l'exécution JavaScript par les crawlers. [1][2]
Comparaison SEO et performances
| Mode | Quand le HTML est généré | Contenu dans le HTML initial | Fraîcheur | Coût par requête | SEO |
|---|---|---|---|---|---|
| SSG | Build | Oui | Jusqu'au prochain build | Très faible | Très bon |
| ISR | Build ou revalidation | Oui | Selon la revalidation | Faible | Très bon |
| SSR | Chaque requête | Oui | Très élevée | Plus élevé | Très bon |
| CSR | Dans le navigateur | Souvent limité | Élevée après fetch | Serveur faible, client plus élevé | Possible, moins optimal |
Il n'existe pas de classement universel. SSG et ISR ont souvent l'avantage du cache et du coût, SSR celui de la fraîcheur, CSR celui de la flexibilité côté client. [6][9][13]
Pour le SEO, SSG, ISR et SSR peuvent renvoyer immédiatement du HTML significatif. CSR peut être indexé par Google, mais nécessite une étape de rendu supplémentaire. [1][9]
Core Web Vitals : le mode de rendu n'est qu'un facteur
| Métrique | Bon | Mauvais | Mesure |
|---|---|---|---|
| LCP | ≤ 2.5 s | > 4.0 s | Chargement du contenu principal |
| INP | ≤ 200 ms | > 500 ms | Réactivité aux interactions |
| CLS | ≤ 0.1 | > 0.25 | Stabilité visuelle |
Google utilise les Core Web Vitals dans ses systèmes de classement, sans garantir qu'un bon score entraîne une position élevée. Les métriques actuelles sont LCP, INP et CLS. [4][5]
Les seuils recommandés sont LCP ≤ 2,5 s, INP ≤ 200 ms et CLS ≤ 0,1 au 75e percentile. [4][8]
SSG peut livrer vite mais souffrir d'un INP médiocre avec trop de JavaScript. SSR peut améliorer le premier rendu, mais un backend lent peut dégrader le TTFB. [6][7]
Hydratation : SSR ne s'arrête pas à l'envoi du HTML
De nombreux frameworks hydratent le résultat SSR ou SSG en attachant ensuite état et gestionnaires d'événements. web.dev avertit que la réhydratation complète peut augmenter TBT et dégrader INP. [6]
Une page peut donc sembler prête alors que les interactions restent momentanément bloquées.
Réduire le JavaScript, utiliser code splitting, lazy loading et hydratation partielle ou différée aide. Nuxt 4 documente des pages presque statiques avec très peu de JavaScript. [7][14]
Cache et fraîcheur : la différence clé
SSG réutilise le résultat jusqu'au prochain build. ISR ajoute la revalidation. SSR peut recalculer à chaque requête, tout en pouvant utiliser un cache serveur ou CDN. [6][13][16]
Le choix dépend donc de l'âge maximal acceptable des données. Quelques minutes de retard peuvent convenir à ISR, un solde de compte doit généralement être actuel.
Le cache devrait idéalement être invalidé en fonction des vraies modifications de contenu.
Le SEO ne se limite pas au rendu
Le HTML n'annule pas le besoin de statuts HTTP corrects, liens crawlables, canonical, sitemap, titres et métadonnées. Google recommande une URL propre pour chaque contenu important et des liens accessibles aux robots. [1][2]
Une mauvaise implémentation SSR peut toujours produire des 200 erronés, doublons ou métadonnées incorrectes. Le rendu est un élément du SEO technique, pas son remplacement.
Google ne recommande plus Dynamic Rendering comme solution durable et préfère SSR, static rendering ou hydration. [3]
Quelle stratégie selon le type de page
Landing pages, blogs et documentation conviennent généralement à SSG. Catalogues importants ou actualités périodiques conviennent souvent à ISR. Les pages publiques dépendantes de la requête peuvent nécessiter SSR. Les tableaux de bord privés peuvent rester CSR. [9][13]
Un e-commerce peut combiner une catégorie statique, ISR pour les produits, SSR pour les données de session et CSR pour les filtres interactifs.
Le choix doit se faire par route.
Réalité 2026 : les modèles hybrides deviennent plus fins
Next.js 16.3.4 documente Cache Components, `use cache`, la revalidation des données et de l'UI, une coque statique et le streaming pour les données de requête. Le guide de cache actuel a été mis à jour le 25 août 2026. [11]
Nuxt 4 permet `prerender`, `ssr`, `swr` et `isr` par route via Route Rules. [13][14]
Les quatre termes restent utiles, mais ne décrivent plus chaque composant d'une application moderne.
Améliorer progressivement un CSR pour le SEO
Commencez par identifier les routes publiques qui doivent réellement attirer du trafic organique. Il n'est pas utile de convertir un dashboard privé en SSR pour uniformiser l'architecture.
Placez ensuite contenu critique, titres, métadonnées et liens dans du HTML généré avant le JavaScript client. Google recommande SSR ou prerendering plutôt que Dynamic Rendering. [1][3]
Validez enfin dans Search Console, le HTML rendu et les données terrain Core Web Vitals.
Règle de décision pratique
Si une page peut être préparée à l'avance et son contenu est commun à tous, commencez par SSG. Si elle change périodiquement, envisagez ISR. Si le résultat doit dépendre de la requête et apparaître en HTML, utilisez SSR. Pour une application privée sans objectif SEO, CSR suffit souvent. [9][13]
Validez ensuite avec TTFB, LCP, INP, CLS, coût serveur, fréquence des changements, nombre de pages et besoins de personnalisation.
- Le contenu principal doit-il être indexé ?
- Le HTML peut-il être généré avant la requête ?
- Quelle fraîcheur est nécessaire ?
- Le résultat dépend-il des cookies, de la session ou de la requête ?
- Combien de routes faut-il générer ?
- La page peut-elle être mise en cache sans risque ?
- Combien de JavaScript le navigateur doit-il exécuter ?
- Quels sont les LCP, INP, CLS et TTFB réels en production ?
