Next.js : pourquoi ce framework est devenu le standard des sites performants

Ce que Next.js ajoute à React

React gère le rendu d'interfaces. Il ne sait pas comment les pages sont routées, comment les données sont chargées côté serveur, ni comment les fichiers HTML sont générés et distribués. Next.js prend en charge tout ça.

Concrètement, voilà ce que le framework apporte nativement :

• Routage basé sur le système de fichiers : chaque fichier dans le dossier app/ ou pages/ devient une route automatiquement, sans configuration de router manuelle.
• Rendu flexible : SSG, SSR, ISR et React Server Components sont disponibles et combinables page par page.
• Optimisation des assets : next/image pour les images (conversion WebP, lazy loading, sizing adaptatif), next/font pour les polices (hébergement local, pas de requête tierce).
• API Routes : la possibilité de créer des endpoints backend directement dans le projet, sans serveur séparé pour les cas simples.
• Middleware : du code exécuté à la périphérie (Edge) avant chaque requête, utile pour l'authentification, la redirection et la personnalisation.

Les quatre modes de rendu : comprendre quand utiliser quoi

C'est l'une des forces majeures de Next.js. Contrairement à Create React App (100% client) ou à un serveur Express classique (100% serveur), Next.js vous laisse choisir la stratégie de rendu par page en fonction des besoins réels.

SSG : pages générées au build

Le HTML est produit une fois pour toutes au moment du déploiement. C'est le mode le plus performant : les pages sont servies depuis un CDN, sans calcul côté serveur. Idéal pour les pages dont le contenu est stable : accueil, page "À propos", articles de blog, pages produits.

SSR : rendu à chaque requête

Le HTML est généré à chaque fois qu'un utilisateur charge la page. Le contenu est toujours frais, ce qui est pertinent pour les dashboards, les pages de compte, ou les pages dont le contenu change en temps réel.

ISR : revalidation incrémentale

La page est statique, mais elle se régénère automatiquement en arrière-plan après un délai configurable. C'est souvent le meilleur compromis pour les catalogues e-commerce, les articles de presse ou tout contenu qui change fréquemment mais pas en temps réel.

React Server Components (RSC)

Introduits en Next.js 13 via l'App Router, les Server Components s'exécutent uniquement côté serveur. Ils n'envoient pas de JavaScript au navigateur. Pour des composants qui affichent des données sans interactivité (listes de produits, articles, menus), c'est un gain de performance concret : moins de JS dans le bundle, rendu plus rapide sur mobile.

L'App Router : ce qui a changé avec Next.js 13

Next.js 13 a introduit l'App Router, une refonte profonde de l'architecture des projets. Le pages/ router historique reste supporté pour la compatibilité, mais les nouveaux projets partent sur app/.

Les changements majeurs :

Les layouts imbriqués. Chaque segment de route peut avoir son propre layout. Plus besoin de wrapper global qui re-rend tout à chaque navigation : les parties communes de l'interface restent montées, seul le contenu qui change est mis à jour. C'est plus proche de ce que font les applications natives.

La cohabitation Server et Client Components. Dans un même projet, certains composants s'exécutent côté serveur, d'autres côté client. La règle est simple : par défaut, tout est Server Component. On ajoute "use client" uniquement aux composants qui ont besoin d'interactivité (hooks, événements, état local). Le résultat : un bundle JS minimal, des performances bien meilleures sur les appareils modestes.

Le Data Fetching simplifié. Fini les getServerSideProps et getStaticProps. Dans l'App Router, on fait le fetch de données directement dans le composant serveur, avec les API fetch natives et les options de cache de Next.js. Plus lisible, plus proche de la logique composant.

Pourquoi autant d'équipes ont adopté Next.js

La réponse courte : parce qu'il résout des problèmes réels sans imposer trop d'opinions.

Pour le SEO d'abord. Un SPA React classique envoie du HTML quasi-vide au crawler. Le JavaScript doit s'exécuter pour que le contenu apparaisse. Next.js envoie du HTML complet d'emblée, ce qui rend l'indexation plus fiable et plus rapide. C'est un avantage structurel sur tout projet qui dépend du trafic organique.

Pour les performances ensuite. Les Core Web Vitals (LCP, INP, CLS) sont des facteurs de classement Google. Le rendu statique, l'optimisation des images et des fonts, le code splitting automatique : Next.js couvre les principaux leviers de performance par défaut. Une équipe qui part sur Next.js part avec une longueur d'avance sur ces métriques.

Pour la scalabilité. Que vous ayez 10 pages ou 100 000, l'architecture tient. Les gros catalogues e-commerce, les médias avec des milliers d'articles, les plateformes SaaS avec des espaces utilisateurs : Next.js a été utilisé à chacune de ces échelles.

Ce qu'il faut garder en tête

Next.js est développé et maintenu principalement par Vercel. La plateforme de déploiement la plus optimisée pour Next.js est (sans surprise) Vercel. Déployer ailleurs (Netlify, AWS, serveur VPS) reste possible, mais certaines fonctionnalités avancées (Edge Middleware, ISR avec revalidation à la demande) s'intègrent plus naturellement sur Vercel. C'est un point à considérer si vous avez des contraintes d'infrastructure ou de souveraineté des données.

La courbe d'apprentissage de l'App Router est réelle. Si votre équipe vient du Pages Router ou de React sans Next.js, les Server Components et les layouts imbriqués demandent du temps pour être vraiment maîtrisés. Ce n'est pas rédhibitoire, mais ça se prépare.

Si vous vous posez encore la question du choix entre Next.js et d'autres frameworks comme Gatsby ou Nuxt.js, sachez que Next.js n'est pas parfait, mais il est difficile de trouver un autre framework qui couvre autant de besoins réels avec une aussi bonne intégration React.