Skip to main content

​
Rendu Côté Serveur (SSR - Server Side Rendering)

Dans le modèle SSR, le serveur prépare la page web complète (y compris les données) sous forme de HTML prêt à l’emploi avant de l’envoyer au navigateur du client. Pour chaque nouvelle page ou navigation, le serveur régénère et renvoie la page complète. SSR Mécanisme
  1. Requête : L’utilisateur clique sur un lien ou tape une URL.
  2. Traitement Serveur : Le serveur récupère les données, exécute la logique de l’application et génère le HTML final.
  3. Réponse : Le serveur envoie le HTML complet au navigateur.
  4. Hydratation (Hydration) : Le JavaScript est ensuite chargé en arrière-plan et “prend le contrôle” de la page statique, la rendant interactive (gestion des événements, formulaires, etc.).
Avantages
  • Performance Perçue (TTI) : Le temps d’affichage du premier contenu (First Contentful Paint - FCP) est très rapide, car le HTML est immédiatement disponible.
  • SEO Optimal : Les moteurs de recherche (Google, Bing) voient le contenu complet de la page dès le premier chargement, ce qui améliore l’indexation.
  • Bonne Expérience sur Connexions Lentes : L’utilisateur reçoit du contenu utile même si le JavaScript prend du temps à se charger.
Inconvénients
  • Charge Serveur (Server Load) : Le serveur doit exécuter la logique de rendu pour chaque requête, ce qui augmente l’utilisation des ressources et peut entraîner des goulots d’étranglement lors de pics de trafic.
  • Temps de Réponse Global (TTFB) : Le Time to First Byte (TTFB) peut être plus long, car le serveur doit attendre les données et générer le HTML avant d’envoyer la première réponse.
  • Flash d’Inactivité : Il peut y avoir un moment où la page est visible mais non interactive (avant l’hydratation).
Cas d’Usage
  • Sites web critiques pour le SEO (blogs, sites d’actualités, e-commerce).
  • Applications nécessitant un chargement initial très rapide.
  • Projets utilisant des frameworks optimisés pour le SSR (Next.js, Nuxt.js).

​
Application Mono-Page (SPA - Single Page Application)

Une SPA est une application web qui charge une seule fois le code HTML, CSS et JavaScript initial. Les interactions utilisateur et les navigations suivantes se font en manipulant dynamiquement le DOM et en récupérant les données nécessaires via des appels API (AJAX/Fetch), sans rechargement complet de la page. SPA Mécanisme
  1. Chargement Initial : L’utilisateur accède à l’URL. Le serveur envoie un HTML minimal (souvent juste une balise <div> vide) et l’ensemble des bundles JavaScript/CSS.
  2. Rendu Client : Le JavaScript prend le relais et exécute la logique de rendu dans le navigateur, construisant l’interface utilisateur.
  3. Navigation Interne : Lorsque l’utilisateur clique sur un lien, l’application intercepte l’événement, change l’URL via l’API History du navigateur, et fait un appel API pour récupérer uniquement les données nécessaires (souvent JSON).
  4. Mise à Jour : Le JavaScript met à jour uniquement les parties du DOM qui ont changé.
Avantages
  • Expérience Utilisateur Fluide : Sensation de “native app” sans rechargement complet, rendant l’application plus rapide et réactive après le chargement initial.
  • Faible Charge Serveur : Le serveur agit uniquement comme une API (Stateless API), gérant les données et la logique métier sans se soucier du rendu de l’interface utilisateur.
  • Séparation des Préoccupations : Front-end et Back-end sont complètement découplés, facilitant la gestion et le développement par des équipes séparées.
Inconvénients
  • SEO Problématique : Les moteurs de recherche peuvent avoir des difficultés à indexer le contenu, car la page initiale est souvent vide (bien que les crawlers modernes soient de plus en plus capables d’exécuter le JavaScript).
  • Temps de Chargement Initial Lent : Le temps de chargement initial (particulièrement le JavaScript) peut être long, retardant le Time to Interactive (TTI).
  • Complexité Client : Déplacer la logique de routage et de gestion d’état vers le client augmente la complexité du code client.
Cas d’Usage
  • Tableaux de bord complexes (dashboards) et outils d’administration.
  • Applications mobiles hybrides ou progressives (PWA).
  • Applications utilisant des frameworks comme React, Vue ou Angular.

​
Solutions Hybrides et Alternatives

Pour combiner les avantages du SSR (SEO, performance initiale) et du SPA (fluidité après chargement), de nouveaux modèles et techniques ont émergé :
ModèleDescriptionAvantages ClésUtilisé Par
Génération de Sites Statiques (SSG)Le HTML complet est généré au moment de la construction (build time), puis servi via un CDN. Il n’y a pas de serveur de rendu actif.Ultra-rapide, sécurisé, excellente performance et SEO.Jamstack, Gatsby, Next.js (export), Astro
Rendu Isomorphe (Universal Rendering)Le code d’application s’exécute à la fois côté serveur (pour le premier chargement) et côté client (pour les navigations suivantes).Combine le meilleur du SSR (SEO, FCP) et du SPA (fluidité).Next.js, Nuxt.js
Rendu au Moment de l’Exécution (Edge Rendering)Le rendu est effectué sur des serveurs CDN distribués (Edge), proches de l’utilisateur, réduisant la latence du TTFB.Performance encore améliorée par la proximité géographique.Cloudflare Workers, Vercel Edge Functions