Optimisation des Performances Next.js : Le Guide Complet 2026

J'ai passé les quatre dernières années à optimiser les applications Next.js pour des clients allant de boutiques e-commerce générant 50M$/an à des dashboards SaaS avec 100k+ utilisateurs actifs quotidiens. Certains de ce que j'ai appris correspond parfaitement à la documentation. Beaucoup ne correspond pas. Ceci est le guide que j'aurais aimé qu'on me remette au démarrage -- mis à jour pour Next.js 15 et les patterns qui comptent vraiment en 2026.

La performance n'est pas une fonctionnalité qu'on ajoute à la fin. C'est une série de décisions qu'on prend dès le premier jour, et chacune se compose. Manquez quelques appels importants au début, et vous vous retrouvez face à une réécriture. Maîtrisez-les, et votre app semble fonctionner sur la machine locale de l'utilisateur.

Entrons dans les détails.

Table des matières

Optimisation des Performances Next.js : Le Guide Complet 2026

Comprendre les Fondamentaux des Performances Next.js 15

Next.js 15 (stable depuis fin 2025) a apporté des changements significatifs à la façon dont les performances fonctionnent sous le capot. Le bundler Turbopack est maintenant le défaut pour les builds de développement et de production. L'App Router est complètement mature. Et le comportement de mise en cache -- qui a confus à peu près tout le monde dans Next.js 14 -- a été rationalisé.

Voici ce que vous devez intérioriser : Next.js vous offre plusieurs stratégies de rendu, et choisir la mauvaise pour une page donnée est la plus grande erreur de performance que je vois. La génération statique, le rendu côté serveur, la régénération statique incrémentale, le pré-rendu partiel, le streaming -- chacun a un cas d'utilisation spécifique. Utiliser SSR pour une page marketing qui change une fois par semaine, c'est juste brûler du calcul pour rien.

Le Modèle Mental des Performances

Pensez aux performances de Next.js selon trois couches :

  1. Décisions au moment de la construction -- Ce qui est pré-rendu, ce qui est dynamique, comment le code se divise
  2. Exécution au moment du serveur -- À quelle vitesse votre serveur répond, mise en cache, edge vs. origine
  3. Expérience au moment du client -- Taille du bundle, coût d'hydratation, préparation de l'interaction

Chaque couche multiplie les autres. Une réponse serveur rapide ne signifie rien si vous envoyez 500KB de JavaScript qui prend 3 secondes à hydrater sur un téléphone Android milieu de gamme.

Mesurer ce qui Compte Vraiment

Avant d'optimiser quoi que ce soit, vous devez mesurer. Et vous devez mesurer les bonnes choses.

Les Core Web Vitals restent les signaux de classement de Google en 2026, mais les seuils se sont resserrés. Voici où les choses en sont :

Métrique Bon Nécessite une Amélioration Mauvais
LCP (Largest Contentful Paint) ≤ 2.0s 2.0s – 3.5s > 3.5s
INP (Interaction to Next Paint) ≤ 150ms 150ms – 300ms > 300ms
CLS (Cumulative Layout Shift) ≤ 0.1 0.1 – 0.25 > 0.25
TTFB (Time to First Byte) ≤ 400ms 400ms – 800ms > 800ms

Les Outils que J'Utilise Vraiment

  • Vercel Speed Insights -- Si vous utilisez Vercel, c'est une évidence. Données d'utilisateurs réels, pas synthétiques.
  • next/bundle-analyzer -- Lancez ceci chaque semaine. La taille du bundle augmente discrètement quand vous ne regardez pas.
  • Onglet Performance des Chrome DevTools -- Toujours l'étalon-or pour déboguer les problèmes d'hydratation.
  • WebPageTest -- Pour tester sur des appareils réels depuis des emplacements réels. La vue filmstrip est inestimable.
  • Sentry Performance Monitoring -- Pour suivre les vrais temps de réponse des API et les durées de rendu des composants serveur en production.
# Ajouter l'analyseur de bundle à votre projet
npm install @next/bundle-analyzer

// next.config.mjs
import withBundleAnalyzer from '@next/bundle-analyzer';

const config = withBundleAnalyzer({
  enabled: process.env.ANALYZE === 'true',
})({
  // votre config ici
});

export default config;

Lancez ANALYZE=true npm run build et regardez vraiment la sortie. Je vous garantis que vous trouverez au moins une bibliothèque qui est beaucoup plus grosse que vous l'aviez prévu.

Composants Serveur : La Plus Grande Victoire que Vous Sous-Utilisez Probablement

Les Composants Serveur sont la plus grande amélioration des performances dans les Modern Next.js. Ils envoient zéro JavaScript au client. Zéro. Le HTML est rendu sur le serveur, envoyé en streaming au navigateur, et le composant n'est jamais hydraté.

Mais voici où les gens se trompent : ils ajoutent 'use client' trop rapidement. J'ai revu des bases de code où 80% des composants étaient des composants client parce que les développeurs avaient l'habitude du modèle mental de l'ancien Pages Router. Chaque directive 'use client' est une frontière d'hydratation. Chaque frontière d'hydratation est du JavaScript que le navigateur doit télécharger, analyser et exécuter.

La Règle que Je Suis

Gardez les composants comme des Composants Serveur par défaut. Ajoutez 'use client' uniquement quand vous en avez absolument besoin :

  • Gestionnaires d'événements (onClick, onChange, etc.)
  • useState, useEffect, useRef
  • API spécifiques du navigateur (localStorage, window, etc.)
  • Bibliothèques tierces côté client qui utilisent des hooks

Modèle de Composition

Quand vous avez besoin d'interactivité dans une petite partie d'un composant plus grand, ne rendez pas tout le composant client. À la place :

// app/product/[id]/page.tsx (Composant Serveur)
import { getProduct } from '@/lib/products';
import { AddToCartButton } from '@/components/AddToCartButton';
import { ProductReviews } from '@/components/ProductReviews';

export default async function ProductPage({ params }: { params: { id: string } }) {
  const product = await getProduct(params.id);

  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      {/* Seul ce petit bouton est un composant client */}
      <AddToCartButton productId={product.id} price={product.price} />
      {/* Toute cette section d'avis reste sur le serveur */}
      <ProductReviews productId={product.id} />
    </div>
  );
}

// components/AddToCartButton.tsx
'use client';

export function AddToCartButton({ productId, price }: { productId: string; price: number }) {
  const handleClick = () => {
    // logique du panier
  };

  return <button onClick={handleClick}>Ajouter au Panier -- ${price}</button>;
}

Ce seul modèle a réduit de 40-60% les tailles de bundle dans les projets sur lesquels nous avons travaillé via notre pratique de développement Next.js.

Optimisation des Performances Next.js : Le Guide Complet 2026 - architecture

Optimisation de la Taille du Bundle

Turbopack dans Next.js 15 gère le tree-shaking mieux que webpack ne l'a jamais fait, mais il ne peut pas vous sauver des mauvaises importations.

Les Importations Nommées Comptent

// MAUVAIS -- importe toute la bibliothèque
import _ from 'lodash';
const sorted = _.sortBy(items, 'name');

// BON -- importe uniquement ce dont vous avez besoin
import sortBy from 'lodash/sortBy';
const sorted = sortBy(items, 'name');

// MEILLEUR -- avez-vous vraiment besoin de lodash ?
const sorted = items.toSorted((a, b) => a.name.localeCompare(b.name));

Gonfleurs Courants de Bundle en 2026

Bibliothèque Taille Typique (gzipped) Alternative Économies de Taille
moment.js 72KB date-fns (tree-shakeable) ~60KB
lodash (complet) 71KB JS Natif / lodash-es ~65KB
chart.js 65KB lightweight-charts ~45KB
react-icons (tous) 40KB+ Packages d'icônes individuels ~35KB
framer-motion 44KB motion (lite) ou CSS ~30KB

Importations Dynamiques pour les Composants Lourds

import dynamic from 'next/dynamic';

const HeavyChart = dynamic(() => import('@/components/Chart'), {
  loading: () => <div className="h-64 animate-pulse bg-gray-100 rounded" />,
  ssr: false, // Ne pas rendu sur serveur si c'est browser-only
});

J'utilise les importations dynamiques pour tout ce qui fait plus de 20KB qui n'est pas au-dessus de la ligne de flottaison. Graphiques, éditeurs de texte enrichi, cartes, modales complexes -- tout en chargement lazy.

Optimisation des Images et Médias

Le composant next/image s'est considérablement amélioré dans Next.js 15. Il supporte maintenant AVIF par défaut (aux côtés de WebP), et la détection de dimensionnement automatique est plus fiable.

Optimisation Critique des Images

import Image from 'next/image';

// Image hero -- au-dessus de la ligne de flottaison, nécessite la priorité
<Image
  src="/hero.jpg"
  alt="Présentation du produit"
  width={1200}
  height={630}
  priority // Précharge cette image
  sizes="100vw"
  quality={80} // 80 est généralement le point optimal
/>

// Image en dessous de la ligne de flottaison -- chargement lazy par défaut
<Image
  src="/feature.jpg"
  alt="Détail de la fonctionnalité"
  width={600}
  height={400}
  sizes="(max-width: 768px) 100vw, 50vw"
  placeholder="blur"
  blurDataURL={feature.blurHash}
/>

L'attribut `sizes` N'est Pas Optionnel

Je vois cela ignoré constamment. Sans un attribut sizes approprié, le navigateur télécharge la plus grande variante d'image indépendamment de la fenêtre d'affichage. Sur mobile, cela pourrait signifier charger une image 2400px de large pour un écran 375px. Spécifiez vos sizes. À chaque fois.

Optimisation Vidéo

Pour la vidéo, n'utilisez pas la balise <video> avec un énorme MP4. En 2026, le déplacement est :

  1. Transcoder en plusieurs qualités en utilisant FFmpeg ou un service comme Mux
  2. Utiliser le streaming HLS pour tout ce qui dépasse 10 secondes
  3. Pour les courtes animations, envisager WebM ou même AVIF animé
  4. Charger les vidéos en lazy en dessous de la ligne de flottaison avec IntersectionObserver

Stratégies d'Extraction et de Mise en Cache des Données

Next.js 15 a simplifié la mise en cache comparé aux défauts déroutants dans 14. Le changement clé : rien n'est mis en cache par défaut plus maintenant. Vous optez explicitement pour la mise en cache. C'est beaucoup plus judicieux.

Mise en Cache avec la Directive `use cache`

Next.js 15 a introduit la directive use cache (actuellement en canary, attendu stable en 15.2) :

async function getProducts() {
  'use cache';
  const products = await db.products.findMany();
  return products;
}

Pour l'API fetch, la mise en cache est contrôlée explicitement :

// Pas de mise en cache (défaut dans Next.js 15)
const data = await fetch('https://api.example.com/data');

// Mise en cache jusqu'à la revalidation manuelle
const data = await fetch('https://api.example.com/data', {
  cache: 'force-cache',
});

// Revalidation tous les 60 secondes
const data = await fetch('https://api.example.com/data', {
  next: { revalidate: 60 },
});

Stratégie de Mise en Cache par Type de Contenu

Type de Contenu Stratégie Revalidation Exemple
Pages marketing Statique (au moment de la construction) Au déploiement Page d'accueil, À Propos
Listes de produits ISR 60-300 secondes Pages de catégorie
Tableau de bord utilisateur Dynamique (pas de mise en cache) À chaque requête Paramètres de compte
Articles de blog ISR 3600 secondes Contenu piloté par CMS
Résultats de recherche Dynamique + cache client Modèle SWR Page de recherche
Données API Cache serveur + CDN Varie REST/GraphQL

Pour les projets utilisant un CMS sans tête, ce qui est la plupart de ce que nous construisons dans notre pratique de développement CMS sans tête, ISR avec revalidation déclenchée par webhook est l'étalon-or. Les mises à jour de contenu apparaissent en quelques secondes sans reconstruire tout le site.

Performance du Runtime Edge et du Middleware

Le Runtime Edge exécute votre code sur les nœuds CDN proches des utilisateurs. Le TTFB baisse considérablement -- nous avons mesuré 50-150ms TTFB à partir du edge par rapport à 300-800ms à partir d'une seule région d'origine.

Mais il y a un piège : le Runtime Edge ne supporte pas toutes les API Node.js. Pas de fs, crypto limité, pas de modules natifs. Votre code s'exécute dans un isolat V8, pas un processus Node.js complet.

Quand Utiliser Edge

  • Middleware (vérifications d'authentification, redirections, tests A/B)
  • Routes API simples qui ne nécessitent pas de connexions à la base de données
  • Pages avec personnalisation qui ne peuvent pas être mises en cache statiquement

Quand Éviter Edge

  • Requêtes lourdes de base de données (le pooling de connexions ne fonctionne pas bien au edge)
  • Routes utilisant des bibliothèques spécifiques à Node.js
  • N'importe quoi nécessitant plus de 25ms de temps CPU (les fonctions edge ont des limites strictes)
// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  // Redirection rapide basée sur la géolocalisation -- s'exécute au edge
  const country = request.geo?.country;

  if (country === 'DE' && !request.nextUrl.pathname.startsWith('/de')) {
    return NextResponse.redirect(new URL('/de' + request.nextUrl.pathname, request.url));
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
};

Gardez le middleware maigre. Chaque milliseconde dans le middleware s'ajoute à chaque chargement de page.

Optimisation de la Base de Données et de la Couche API

Pooling de Connexion

Les fonctions sans serveur s'allument et s'éteignent constamment. Sans pooling de connexion, chaque invocation ouvre une nouvelle connexion à la base de données. À grande échelle, cela tue votre base de données.

Utilisez un pooler de connexion :

  • PgBouncer pour PostgreSQL (Supabase et Neon incluent ceci)
  • Prisma Accelerate si vous utilisez Prisma (ajoute un pool de connexion + cache global)
  • Drizzle avec postgres.js gère les connexions efficacement hors de la boîte

Modèles d'Optimisation de Requête

// MAUVAIS -- problème de requête N+1
const posts = await db.post.findMany();
for (const post of posts) {
  post.author = await db.user.findUnique({ where: { id: post.authorId } });
}

// BON -- requête unique avec join
const posts = await db.post.findMany({
  include: { author: true },
});

// MEILLEUR -- sélectionner uniquement les champs dont vous avez besoin
const posts = await db.post.findMany({
  select: {
    id: true,
    title: true,
    slug: true,
    author: {
      select: { name: true, avatar: true },
    },
  },
});

Extraction de Données Parallèle

Ceci est l'un des modèles les plus impactants et il est criminellement sous-utilisé :

// MAUVAIS -- séquentiel (temps total = somme de tous les fetches)
const products = await getProducts();
const categories = await getCategories();
const banners = await getBanners();

// BON -- parallèle (temps total = fetch le plus lent)
const [products, categories, banners] = await Promise.all([
  getProducts(),
  getCategories(),
  getBanners(),
]);

J'ai vu ce seul changement réduire les temps de chargement de page de moitié.

Sélection de la Stratégie de Rendu

Next.js 15 vous offre cinq stratégies de rendu. Voici comment je décide :

Pré-rendu Partiel (PPR)

PPR est la plus nouvelle et la plus intéressante option. Elle pré-rend statiquement le shell d'une page au moment de la construction, puis envoie en streaming le contenu dynamique. Les utilisateurs voient une réponse statique instantanée pendant que le contenu personnalisé se charge.

// app/page.tsx -- PPR activé
import { Suspense } from 'react';
import { StaticHero } from '@/components/StaticHero';
import { PersonalizedRecommendations } from '@/components/Recommendations';

export default function HomePage() {
  return (
    <div>
      {/* Shell statique -- servi depuis CDN instantanément */}
      <StaticHero />

      {/* Contenu dynamique -- envoyé en streaming */}
      <Suspense fallback={<RecommendationsSkeleton />}>
        <PersonalizedRecommendations />
      </Suspense>
    </div>
  );
}

Activez PPR dans votre config :

// next.config.mjs
export default {
  experimental: {
    ppr: 'incremental',
  },
};

Pour les sites e-commerce et riches en contenu, PPR vous donne le meilleur des deux mondes -- chargements rapides au niveau CDN avec contenu personnalisé.

Gestion des Scripts Tiers

Les scripts tiers sont les assassins silencieux des performances. Analytiques, widgets de chat, suiveurs d'annonces, outils de test A/B -- ils s'accumulent rapidement.

Utiliser `next/script` Stratégiquement

import Script from 'next/script';

// Analytiques -- charger après que la page soit interactive
<Script
  src="https://www.googletagmanager.com/gtag/js?id=G-XXXXX"
  strategy="afterInteractive"
/>

// Widget de chat -- charger quand inactif
<Script
  src="https://widget.intercom.io/widget/xxxxx"
  strategy="lazyOnload"
/>

// Test A/B critique -- doit charger avant le paint
<Script
  src="https://cdn.optimizely.com/js/xxxxx.js"
  strategy="beforeInteractive"
/>

Soyez impitoyable. Chaque script que vous ajoutez coûte du temps à vos utilisateurs. Je recommande d'auditer les scripts tiers trimestriellement. Au moins la moitié du temps, vous trouverez des scripts pour des outils que personne dans l'équipe n'utilise plus.

Partytown pour le Chargement Basé sur les Workers

Pour les scripts tiers non critiques, envisagez Partytown. Il déplace les scripts vers un web worker, libérant le thread principal :

<Script
  src="https://example.com/analytics.js"
  strategy="worker" // S'exécute dans un web worker via Partytown
/>

Infrastructure et Déploiement

Où et comment vous déployez compte plus que la plupart des développeurs ne le pensent.

Comparaison des Plateformes pour Next.js en 2026

Plateforme Support SSR Fonctions Edge Cold Start Prix de Démarrage
Vercel Complet Oui (global) ~50ms $20/mois (Pro)
Cloudflare Pages Complet (via OpenNext) Oui (global) ~10ms $5/mois
AWS Amplify Complet Limité ~200ms Pay-per-use
Netlify Complet Oui (Deno) ~100ms $19/mois (Pro)
Auto-hébergé (Docker) Complet Non N/A Coût du serveur
Coolify / SST Complet Dépend ~150ms Coût du serveur

Vercel est toujours le chemin de moindre résistance pour Next.js. Ils construisent le framework, ils optimisent la plateforme pour celui-ci. Mais Cloudflare Pages avec OpenNext est devenu un concurrent sérieux en 2026, en particulier pour les projets sensibles aux coûts.

Pour les clients qui ont besoin de déploiements auto-hébergés, nous avons eu de bons résultats avec des conteneurs Docker derrière un CDN. Cela nécessite plus de configuration, mais vous contrôlez entièrement l'infrastructure. Notre page de tarification couvre différents scénarios de déploiement si vous voulez discuter de ce qui a du sens pour votre projet.

Mise en Cache Edge et CDN

Indépendamment de la plateforme, mettez un CDN devant tout. Les ressources statiques doivent avoir des en-têtes de cache immuables. Les pages ISR doivent utiliser stale-while-revalidate. Les réponses API doivent être mises en cache le cas échéant.

// Pour les routes API qui peuvent être mises en cache
export async function GET() {
  const data = await getPopularProducts();

  return Response.json(data, {
    headers: {
      'Cache-Control': 'public, s-maxage=60, stale-while-revalidate=300',
    },
  });
}

Benchmarks et Études de Cas du Monde Réel

Voici les chiffres réels des projets que nous avons optimisés au cours de la dernière année :

Site E-commerce (Shopify Headless + Next.js 15)

  • Avant : LCP 4.2s, INP 380ms, bundle 487KB
  • Après : LCP 1.4s, INP 89ms, bundle 156KB
  • Changements clés : Composants Serveur pour les pages de produits, optimisation des images, suppression de 4 scripts tiers inutilisés, passage du panier côté client aux server actions
  • Impact commercial : Augmentation de 23% du taux de conversion

Dashboard SaaS (Migration Next.js 14 → 15)

  • Avant : Chargement initial 6.8s, TTI 8.2s
  • Après : Chargement initial 2.1s, TTI 2.8s
  • Changements clés : Migration vers App Router, implémentation du streaming pour les tableaux riches en données, ajout de PPR pour les pages mixtes statiques/dynamiques, extraction de données parallèle

Plateforme de Contenu (CMS Sans Tête + Next.js)

  • Avant : TTFB 890ms (SSR), LCP 3.1s
  • Après : TTFB 120ms (ISR + edge), LCP 1.1s
  • Changements clés : Passage de SSR à ISR avec revalidation à la demande, déploiement au edge, optimisation des requêtes CMS

Ce ne sont pas des chiffres cherry-picked. Ils sont représentatifs de ce qui est réalisable quand vous appliquez les modèles de ce guide systématiquement.

Pour les projets construits avec Astro au lieu de Next.js -- en particulier les sites riches en contenu où les exigences JavaScript sont minimales -- les chiffres peuvent être encore plus impressionnants. Nous couvrons cela dans nos capacités de développement Astro.

FAQ

Combien coûte généralement l'optimisation des performances Next.js ?

Cela dépend fortement de la taille et de la complexité de votre application. Pour un site simple, un sprint d'optimisation ciblé de 1-2 semaines peut réaliser des résultats dramatiques. Pour les grandes applications avec des problèmes architecturaux profonds, préparez-vous à 4-8 semaines de refactorisation. Le ROI s'amortit généralement rapidement grâce aux taux de conversion améliorés et aux coûts d'infrastructure réduits. Contactez-nous via notre page de contact si vous voulez une estimation spécifique.

Next.js 15 est-il plus rapide que Next.js 14 ?

Oui, mesurément. Turbopack comme bundler par défaut réduit les temps de construction de 30-50% et produit des bundles légèrement plus petits. Le modèle de mise en cache simplifié réduit la charge serveur inutile. Et le Pré-rendu Partiel, quand utilisé correctement, améliore la performance perçue considérablement. Nous avons vu des améliorations TTFB moyennes de 15-25% après la migration.

Devrais-je utiliser le Pages Router ou l'App Router en 2026 ?

App Router, sans équivoque. Le Pages Router fonctionne toujours et est toujours supporté, mais toute l'innovation de performance se fait dans l'App Router. Composants Serveur, streaming, PPR, server actions -- aucun de ceux-ci n'est disponible dans Pages Router. Si vous démarrez un nouveau projet, il n'y a aucune raison d'utiliser Pages Router.

Comment réduire rapidement la taille du bundle Next.js ?

Lancez d'abord l'analyseur de bundle -- cela vous montre exactement où se trouve le poids. Ensuite : remplacez les bibliothèques lourdes par des alternatives plus légères, utilisez les importations dynamiques pour les composants en dessous de la ligne de flottaison, assurez-vous que vous utilisez des importations nommées à partir de bibliothèques tree-shakeable, et auditez vos directives 'use client'. Ces quatre étapes seules réduisent généralement la taille du bundle de 30-50%.

La plateforme d'hébergement affecte-t-elle vraiment les performances Next.js ?

Plus que prévu. L'infrastructure de Vercel est spécifiquement accordée pour Next.js -- leur réseau edge, l'implémentation ISR et le CDN d'optimisation d'image sont étroitement intégrés. D'autres plateformes fonctionnent bien aussi, mais vous devrez peut-être configurer manuellement des choses que Vercel gère automatiquement. Le facteur le plus important est la distribution géographique -- si vos utilisateurs sont globaux, vous avez besoin de déploiement edge ou d'un CDN, indépendamment de la plateforme.

Quelle est la plus grande erreur de performance Next.js que vous voyez ?

Faire de tout un composant client. J'ai audité des bases de code où toute l'arborescence des pages était enveloppée dans 'use client' parce que le développeur avait besoin d'un gestionnaire onClick au niveau supérieur. Cela force le navigateur à télécharger et hydrater tout, annulant complètement les avantages des Composants Serveur qui rendent Next.js rapide. Restructurez votre arborescence de composants afin que les composants client soient des nœuds petits et au niveau des feuilles.

Comment le Pré-rendu Partiel (PPR) se compare-t-il à l'ISR régulier ?

ISR génère la page entière au moment de la construction et revalidate périodiquement. PPR pré-rend le shell statique au moment de la construction mais laisse des "trous" dynamiques qui sont remplis via le streaming au moment de la requête. PPR est meilleur pour les pages qui mélangent contenu statique et personnalisé -- pensez à une page de produit où la description est statique mais les produits recommandés sont personnalisés. La réponse initiale est tout aussi rapide que du statique pur, mais le contenu dynamique apparaît sans un rechargement complet de page.

Puis-je optimiser les performances de Next.js sans Vercel ?

Absolument. Les optimisations dans ce guide fonctionnent indépendamment de la plateforme d'hébergement. Composants Serveur, optimisation du bundle, optimisation des images, stratégies de mise en cache, extraction de données parallèle -- ce sont des préoccupations au niveau de l'application. Les fonctionnalités spécifiques à la plateforme comme les fonctions edge et le support ISR intégré varient, mais des outils comme OpenNext rendent possible l'exécution d'un Next.js complètement avancé sur Cloudflare, AWS et d'autres plateformes avec des caractéristiques de performance similaires.