Web rendering (rendu web) : SSR, CSR, SSG, ISR et edge

Qu'est-ce que le rendu web (web rendering) ?

Le rendu web est le processus qui transforme le code de l'application et les données en HTML affiché par le navigateur. Tout se joue sur le lieu et le moment : sur le serveur à chaque requête, dans le navigateur après le chargement de JavaScript, ou en amont lors du build. Ce choix détermine la vitesse, le SEO, le coût d'hébergement et la fraîcheur du contenu.

Les principales stratégies de rendu

Comment fonctionne chaque stratégie

• SSG : une étape de build écrit un fichier HTML par URL et un CDN les sert. Rien ne s'exécute par requête : c'est économique et robuste face aux pics de trafic, mais le contenu ne se met à jour qu'après un nouveau build.
• SSR : le serveur construit le HTML de chaque requête. Le contenu est toujours à jour et peut dépendre de l'utilisateur, mais chaque visite consomme du temps serveur et allonge le temps jusqu'au premier octet.
• CSR : le serveur envoie une coquille minimale et un bundle JavaScript, et le navigateur construit la page. La navigation dans l'application est instantanée, mais la première vue attend le téléchargement et l'exécution du bundle.
• ISR : des pages statiques régénérées en arrière-plan après un délai ou sur déclenchement, pour la vitesse du statique avec une obsolescence bornée.
• Rendu à l'edge : du code SSR exécuté sur les points du CDN plutôt que dans une seule région d'origine. La latence baisse pour les utilisateurs éloignés, mais les environnements edge limitent les API et bibliothèques disponibles.

Hydratation : là où serveur et client se rejoignent

SSR et SSG envoient du HTML terminé, mais les parties interactives ont encore besoin de JavaScript. L'hydratation est l'étape où ce JavaScript s'accroche au HTML existant. Elle coûte cher sur les grandes pages, d'où l'hydratation partielle, le streaming et les composants serveur proposés par les frameworks pour envoyer moins de JavaScript.

Exemple : choisir page par page pour une boutique en ligne

• Accueil et guides : SSG, car ils sont identiques pour tous.
• Fiches produit : ISR, pour qu'un changement de prix apparaisse en quelques minutes sans reconstruire tout le catalogue.
• Panier et paiement : CSR ou SSR, car ils dépendent du visiteur et n'ont pas besoin de se positionner.
• Bandeau par pays : rendu à l'edge ou petit script côté client.

Erreurs fréquentes

• Utiliser le CSR pour des pages publiques qui doivent se positionner, puis s'étonner que les aperçus et certains robots voient une page vide.
• Utiliser le SSR pour des pages qui ne changent jamais : plus de coût serveur et un premier octet plus lent sans bénéfice.
• Envoyer un énorme bundle JavaScript par-dessus du HTML rendu côté serveur : la page semble prête mais ignore les clics.
• Mettre en cache au CDN une sortie SSR personnalisée et servir la page d'un utilisateur à un autre.
• Choisir la stratégie par effet de mode au lieu de mesurer de vraies pages.

Rendu, tests de performance et supervision

La stratégie de rendu se lit directement dans les indicateurs qui comptent. Les pages statiques et rendues côté serveur aident en général le Largest Contentful Paint, une hydratation lourde nuit à l'Interaction to Next Paint, et le CSR reporte le travail sur l'appareil du visiteur. Suivez les Core Web Vitals de façon régulière, par exemple avec LoadFocus Page Speed Monitoring. La mise en place est décrite dans l'article comment surveiller les Core Web Vitals avec alertes et rapports (en anglais).

Le SSR change aussi la planification de capacité : chaque requête exécute du code, alors lancez un test de charge avant une mise en production pour voir à partir de quand les temps de réponse montent. Un site servi en statique teste surtout le CDN.

Questions fréquentes : web rendering

SSR ou SSG : lequel choisir ?

SSG quand la page est identique pour tous et change rarement. SSR quand elle dépend de la requête, par exemple d'un cookie, de la localisation ou de données à jour. Si vous avez besoin des deux, régénérez les pages statiques de façon planifiée ou à la demande (ISR).

Le rendu côté client est-il mauvais pour le SEO ?

Pas automatiquement. Google sait exécuter JavaScript, mais cela demande une étape de plus, et d'autres robots ou aperçus de liens peuvent ne voir qu'une coquille vide. Pour les pages publiques qui doivent se positionner, servez du vrai HTML depuis le serveur ou le build.

Quelle différence entre rendu et hydratation ?

Le rendu produit le HTML. L'hydratation est l'étape où le JavaScript du navigateur s'accroche à ce HTML pour que les boutons et formulaires fonctionnent. Une page peut être entièrement rendue et ne pas réagir aux clics tant que l'hydratation n'est pas terminée.

Peut-on mélanger les stratégies de rendu dans un même site ?

Oui. La plupart des frameworks modernes choisissent route par route. Cas typique : pages marketing statiques, fiches produit en ISR et application connectée en rendu côté client.

Quelle stratégie de rendu est la plus rapide ?

Les pages statiques servies depuis un CDN offrent en général le plus faible temps jusqu'au premier octet, car aucun code ne s'exécute à chaque requête. La vitesse dépend aussi du poids de la page, des images et du JavaScript : mesurez vos propres pages plutôt que de vous fier à l'étiquette.