Demo
Page de démonstration
Qu'est-ce que SSR ?
Cette page de démonstration n’est pas un outil destiné aux utilisateurs finaux, mais une petite route de référence pour le rendu côté serveur. Elle montre comment une page Next.js App Router peut récupérer des données sur le serveur, intégrer le résultat dans le premier HTML et charger les traductions de la langue courante. Elle sert donc à vérifier l’infrastructure commune : variables d’environnement, requêtes serveur signées, forme de la réponse API, routage par locale et chargement des traductions. Si cette page fonctionne, le chemin SSR de base est sain avant de déboguer une page d’outil plus complexe. Si elle échoue, la cause se trouve probablement dans la configuration serveur partagée ou la connexion API. Elle doit rester simple pour servir de smoke test après déploiement ou changement de framework.
Comment utiliser
Comment utiliser
- La page appelle automatiquement l'API backend côté serveur
- Le HTML contient du contenu pré-rendu, aucune requête côté client n'est nécessaire
- Consultez les données renvoyées par l'API
- Idéal pour les pages nécessitant une optimisation SEO
Notes de développement
- Utilisez cette page comme test de fumée pour le SSR, le chargement des locales, les requêtes serveur signées et la connectivité API.
- Si cette page échoue, vérifiez la configuration serveur partagée avant de déboguer une page d'outil spécifique.
Cas d’utilisation
Principe technique
Cette page de démo est construite sur Next.js 16 App Router et utilise le rendu côté serveur (SSR) par défaut. Lorsqu'un utilisateur demande la page, le serveur Node.js exécute d'abord le composant React, appelle l'API backend pour obtenir les données, puis renvoie le HTML entièrement rendu au navigateur en une seule réponse. Le navigateur commence immédiatement l'analyse et le rendu du HTML, de sorte que l'utilisateur voit le contenu complet dès la première image sans attendre le téléchargement et l'exécution du JavaScript. Cela contraste fortement avec le rendu côté client (CSR) traditionnel. En CSR, le serveur ne renvoie qu'un squelette HTML presque vide et un lien JS ; le navigateur doit télécharger le bundle JS, exécuter l'initialisation du framework, appeler les API pour récupérer les données, et ce n'est qu'alors qu'il affiche la page. Du point de vue de l'utilisateur, c'est « un écran vide pendant un moment », et c'est encore pire pour les robots d'indexation — la plupart n'exécutent pas le JavaScript et ne voient que le squelette vide. Après le SSR, Next.js injecte également un morceau de JavaScript pour effectuer l'« hydration » : associer le DOM existant à l'arbre de composants React et lier les écouteurs d'événements pour que la page devienne interactive. Le flux complet est analyse HTML -> chargement CSS -> téléchargement JS -> hydration -> page interactive. Parmi les trois Core Web Vitals, le LCP (Largest Contentful Paint) et le CLS (Cumulative Layout Shift) sont généralement meilleurs en SSR, tandis que l'INP (Interaction to Next Paint) dépend de la vitesse d'hydration et de la qualité de l'implémentation des gestionnaires d'événements.
- Next.js App Router : les pages de l'App Router sont des Server Components par défaut, exécutées côté serveur et renvoyant automatiquement du HTML sans configuration supplémentaire.
- SSR vs CSR : le SSR offre un premier rendu rapide et une bonne compatibilité SEO au prix de ressources serveur ; le CSR convient aux tableaux de bord internes et autres scénarios interactifs n'ayant pas besoin de SEO.
- Flux du premier rendu : analyse HTML -> chargement et rendu CSS -> téléchargement et exécution JS -> hydration React -> page interactive ; chaque étape affecte le LCP.
- Compatibilité SEO : les robots principaux comme Googlebot et Bingbot lisent directement le texte HTML ; la sortie SSR d'un contenu complet garantit la couverture d'indexation.
- Seuils Web Vitals : LCP < 2,5 s, INP < 200 ms, CLS < 0,1 sont les seuils « bon » recommandés par Google ; le SSR facilite l'atteinte du LCP et du CLS.
- Requêtes signées : la page de démo appelle l'API backend via serverApiFetch côté serveur, transportant automatiquement X-Timestamp, X-Nonce et X-Sign pour effectuer l'authentification.
Exemples
SSR (Server-Side Rendering)
// app/page.tsx (Server Component par défaut)
export default async function Page() {
const data = await fetch('/api/info').then(r => r.json());
return <div>{data.title}</div>;
}
// Le HTML contient déjà directement <div>contenu réel</div>CSR (Client-Side Rendering)
'use client';
import { useEffect, useState } from 'react';
export default function Page() {
const [data, setData] = useState(null);
useEffect(() => {
fetch('/api/info').then(r => r.json()).then(setData);
}, []);
return <div>{data?.title || 'Loading...'}</div>;
}
// Le HTML du premier rendu ne contient que <div>Loading...</div>Comparaison de vitesse de premier rendu
# SSR
FCP : 0,4s LCP : 0,8s TTI : 1,2s
SEO : les crawlers récupèrent directement le contenu complet
# CSR
FCP : 0,6s LCP : 1,8s TTI : 2,4s
SEO : les crawlers doivent exécuter du JS pour obtenir le contenuFAQ
Que démontre réellement cette page de démonstration ?
C'est une route de référence pour le rendu côté serveur (SSR) qui montre comment une page Next.js App Router peut récupérer des données sur le serveur, intégrer le résultat dans la première réponse HTML, tout en chargeant les libellés localisés corrects. Ce n'est pas un utilitaire pour utilisateur final — c'est un test de bon fonctionnement pour les développeurs.
Les données sont-elles récupérées sur le serveur ou dans le navigateur ?
Sur le serveur. La page appelle serverApiFetch (avec les en-têtes de requête signée de src/lib/sign.ts) à l'intérieur du React Server Component, si bien que le navigateur reçoit une page HTML qui contient déjà les données. Aucun fetch côté client n'a lieu au premier chargement.
Pourquoi la page affiche-t-elle parfois des données obsolètes ?
Next.js peut mettre en cache la réponse SSR en fonction des réglages de revalidation. Si vous voulez des données fraîches à chaque requête, déclarez 'export const dynamic = "force-dynamic"' ou passez {cache: 'no-store'} au fetch. La route de démo utilise le comportement par défaut pour garder l'exemple simple.
Puis-je copier ce schéma pour ma propre page ?
Oui — c'est exactement le but. La route montre comment combiner getTranslations de next-intl avec un fetch côté serveur, puis transmettre le résultat à un Client Component pour l'interactivité. Copiez layout.tsx et page.tsx et remplacez la source de données.
Pourquoi signer les requêtes pour une API interne ?
X-Timestamp / X-Nonce / X-Sign bloquent les attaques par rejeu et garantissent que les requêtes émises depuis le web public proviennent bien d'un client de confiance. La clé de signature est par session pour les utilisateurs connectés, et une valeur par défaut sinon ; voyez src/lib/sign.ts et src/lib/fetch.ts pour l'implémentation.
Cette page existera-t-elle dans les builds de production ?
Elle fait partie de l'application déployée à titre de référence, mais elle n'est pas reliée depuis la page d'accueil ni la liste des outils, et n'est pas mise en avant comme un outil utilisateur. Considérez-la comme de la documentation pour développeurs rendue sous forme de route.
Que regarder pour comprendre l'organisation du projet ?
Commencez par les layout.tsx et page.tsx de cette page, puis lisez src/i18n.ts (configuration des locales), src/i18n/request.ts (chargement global des traductions), src/lib/load-page-messages.ts (traductions par page) et src/lib/fetch.ts (wrappers de requêtes signées).