Rendu côté client (CSR) : définition et compromis

Qu'est-ce que le rendu côté client (CSR) ?

Le rendu côté client (CSR) signifie que le navigateur construit le HTML de la page avec JavaScript au lieu de le recevoir terminé depuis le serveur. Le serveur envoie une petite coquille HTML et un bundle JavaScript ; le script récupère les données, en général auprès d'une API, et crée le contenu dans le DOM. MDN le définit comme l'opposé du rendu côté serveur et précise que les deux peuvent être combinés dans une même application.

Comment fonctionne le rendu côté client

1. Le navigateur demande une URL et reçoit un document HTML minimal, souvent un simple conteneur vide et des balises script.
2. Il télécharge, analyse et exécute le bundle JavaScript.
3. L'application demande ses données à une API.
4. L'application construit le DOM et l'utilisateur voit le contenu.
5. La navigation suivante reste dans le navigateur : l'application change de vue et ne récupère que des données, pas des pages entières. C'est le fonctionnement d'une application monopage (SPA).

Exemple

Un tableau de bord construit avec React charge un fichier HTML de quelques centaines d'octets. Le visiteur voit une page blanche ou un indicateur de chargement jusqu'à ce que le bundle soit chargé, que l'API ait répondu et que les graphiques soient dessinés. Ensuite, passer d'un onglet à l'autre est instantané, car seul du JSON circule sur le réseau.

Avantages

• Navigation rapide dans l'application. Après le premier chargement, les vues changent sans recharger la page.
• Forte interactivité. Tableaux de bord, éditeurs et outils conviennent à une application qui vit dans le navigateur.
• Hébergement simple. La coquille et le bundle sont des fichiers statiques que n'importe quel CDN sert ; seule l'API a besoin de serveurs.

Inconvénients

• Premier contenu plus lent. Rien d'utile n'apparaît avant l'exécution de JavaScript. web.dev note que la quantité de JavaScript tend à croître avec l'application, ce qui peut nuire à l'INP, et que le CSR est difficile à garder rapide sur mobile.
• Le SEO demande du soin. Google traite les pages JavaScript en trois phases : exploration, rendu et indexation. Les pages attendent dans une file de rendu, « quelques secondes, mais cela peut être plus long » (d'après Google Search Central). Google ajoute que le rendu côté serveur ou le prérendu restent une bonne idée, car tous les robots n'exécutent pas JavaScript.
• Dépend de l'appareil. Analyser et exécuter un gros bundle prend plus de temps sur un téléphone lent que sur l'ordinateur d'un développeur.

Erreurs fréquentes

• Livrer un seul bundle énorme. Découpez le code par route et chargez à la demande ce que le premier écran n'utilise pas.
• Récupérer les données en cascade. Un composant qui attend le chargement de son parent avant de demander ses données ajoute un aller-retour complet par niveau.
• Mettre noindex dans la coquille HTML et le retirer avec JavaScript. Google peut sauter le rendu en voyant noindex, si bien que ce retrait ne s'exécute peut-être jamais.
• Tester uniquement sur du matériel rapide. Vérifiez avec un processeur et un réseau bridés, ou sur de vrais appareils milieu de gamme.
• Ne pas fournir de HTML utile aux pages clés. Les pages marketing et de contenu fonctionnent souvent mieux avec la génération statique ou le rendu serveur, avec l'application rendue côté client derrière la connexion.

CSR, SSR et SSG comparés

Le choix porte sur le moment où le HTML est produit. Le rendu peut avoir lieu dans le navigateur (CSR), sur le serveur à chaque requête (SSR) ou à la compilation (SSG). Des frameworks comme Next.js les mélangent page par page, et l'hydratation rend ensuite interactif le HTML produit par le serveur. Une page publique qui doit être trouvée dans les moteurs de recherche convient mal à un CSR pur ; un outil derrière une connexion convient souvent bien.

Tester et surveiller une application CSR

Les mesures de laboratoire comme de terrain comptent, car c'est le navigateur qui fait le travail. La surveillance de la vitesse de page LoadFocus exécute des audits Lighthouse et des contrôles Core Web Vitals planifiés depuis 25 régions cloud et vous alerte quand une page ralentit ; le vérificateur Core Web Vitals donne une mesure ponctuelle, et le guide sur la surveillance des Core Web Vitals avec alertes et rapports détaille la mise en place. L'API derrière l'application est un autre sujet : un test de charge JMeter ou k6 sollicite ses points d'accès, pas le rendu dans le navigateur.

Questions fréquentes : rendu côté client

Quelle différence entre CSR et SSR ?

Avec le CSR, le navigateur construit le HTML avec JavaScript. Avec le SSR, le serveur envoie un HTML déjà construit pour cette requête. Le SSR affiche généralement du contenu plus tôt ; le CSR accélère la navigation ultérieure dans l'application.

Le rendu côté client nuit-il au SEO ?

Pas automatiquement. Google sait exécuter JavaScript, mais les pages attendent dans une file de rendu et tous les robots n'exécutent pas les scripts. Pour les pages qui doivent se positionner, le rendu serveur ou le prérendu est plus sûr.

Quels frameworks utilisent le rendu côté client ?

React, Angular et Vue créent par défaut des applications monopages rendues dans le navigateur. Des méta-frameworks comme Next.js et Nuxt ajoutent le rendu serveur et la génération statique.

Le CSR nuit-il aux Core Web Vitals ?

Cela peut arriver. Un gros bundle retarde le contenu principal et occupe le thread principal, ce qui affecte le chargement et l'INP. Le découpage du code, le chargement différé et un bundle plus léger réduisent le risque.

Quand choisir le rendu côté client ?

Pour les outils derrière une connexion, les tableaux de bord et les applications très interactives dont les écrans n'ont pas besoin d'être visibles dans les moteurs de recherche. Pour les pages de contenu public, envisagez le rendu serveur ou la génération statique.