Ce que change le SSR
Le SSR déplace la génération du balisage initial vers le serveur. Le navigateur reçoit le HTML, puis JavaScript peut hydrater les composants interactifs. Le SSR n’est pas synonyme de génération statique, de mise en cache, de TTFB rapide ou d’indexation réussie.
La preuve se trouve dans le corps de la réponse et le statut d’une URL réelle, et non dans un réglage du framework.
Tester la réponse
Inspectez le HTML initial avec JavaScript désactivé ou une requête brute. Vérifiez le statut, la balise canonical, le texte principal et le comportement en cas d’erreur avant l’hydratation.
- Récupérez le HTML initial.
- Testez une route inexistante.
- Comparez le contenu rendu et le contenu brut.
- Mesurez le TTFB séparément.
- Testez les variantes de cache.
Choisir le mode de rendu
Utilisez le SSR lorsque des données calculées au moment de la requête ou une personnalisation sont nécessaires et que l’origine peut répondre de façon fiable. Une sortie statique ou mise en cache convient souvent mieux aux pages publiques stables.
| Question | Contrôle | Limite |
|---|---|---|
| Contenu initial | Présent dans le HTML de la réponse | Le HTML seul ne garantit pas la qualité |
| Route d’erreur | Statut 404/410/500 correct | L’interface client peut masquer le statut |
| Performance | TTFB et ressources mesurés séparément | Un score unique masque les couches |
Limites du SSR
Une page rendue côté serveur peut quand même être lente, renvoyer une erreur ou cacher du contenu derrière des appels client ultérieurs.