Next.js pour des produits scalables : SSR, SEO & App Router
Patterns de production pour des UIs SEO-first, server components et performances. Au service de plateformes comme TravelOS.
Next.js est un framework React qui rend côté serveur par défaut, ce qui le rend adapté aux pages destinées à être indexées. L’App Router organise l’application en layouts imbriqués et en server components, et n’envoie du JavaScript au navigateur que pour les parties réellement interactives.
SSR vs CSR
Rendu côté serveur pour les pages critiques SEO : landing, destinations, articles. Rendu côté client pour les tableaux de bord et formulaires. Approche hybride pour UX et crawlabilité.
Contenu dynamique avec génération statique quand possible. ISR pour un contenu mis à jour périodiquement.
UI orientée SEO
Métadonnées optimisées par page. OpenGraph et Twitter cards. Données structurées (Schema.org). URLs canoniques.
Génération de sitemap, robots.txt, HTML sémantique. LCP et CLS pour les Core Web Vitals. Ces patterns alimentent TravelOS et d’autres plateformes.
Architecture App Router
App Router avec server components par défaut. Data fetching colocalisé. Streaming pour un rendu progressif. Layouts et routes imbriquées.
Client components uniquement pour l’interactivité. Bundle réduit et chargement initial plus rapide.
Optimisation des performances
next/image pour les images, next/font pour les polices. Lazy loading pour le contenu below-the-fold. Objectif Lighthouse 95+.
Stratégies de cache, edge quand pertinent. JavaScript minimal pour les pages riches en contenu.
Questions fréquentes sur le développement avec Next.js
Quand rendre une page côté serveur plutôt que côté client ?
- Côté serveur pour tout ce qui doit être indexé ou partagé : pages d’accueil, articles, fiches destination ou produit. Côté client pour ce que seul un utilisateur connecté manipule : tableaux de bord, formulaires, filtres. Un robot obligé d’exécuter du JavaScript pour trouver le contenu renoncera parfois.
Quelle différence entre génération statique et ISR ?
- La génération statique construit la page une fois au déploiement et sert le même HTML à tout le monde. L’ISR sert ce HTML en cache mais le reconstruit en arrière-plan après un intervalle défini : un contenu qui change quelques fois par jour reste à jour sans redéployer.
Les server components rendent-ils vraiment un site plus rapide ?
- Ils réduisent le JavaScript téléchargé et exécuté par le navigateur, ce qui améliore généralement le LCP sur les pages riches en contenu. Ils ne sont pas automatiquement plus rapides : un server component qui fait une requête lente bloque toujours la réponse. Le gain est dans le bundle, pas dans la requête.
Comment éviter le contenu dupliqué sur un site Next.js multilingue ?
- Une canonical auto-référente sur chaque page, et des alternates hreflang nommant chaque langue plus x-default. On génère les deux depuis un même helper pour que l’en-tête et le sitemap ne puissent pas diverger, et on ne déclare une alternance que pour une langue qui existe vraiment.