Les performances d’un site Next.js ne viennent pas d’un réglage unique. Elles dépendent de l’architecture de rendu, du poids du JavaScript envoyé au navigateur, de la gestion des images, des polices, des données et du cache. L’objectif est de livrer rapidement un contenu utile, puis d’ajouter l’interactivité uniquement là où elle apporte une vraie valeur.

Choisir une architecture de rendu adaptée

L’App Router de Next.js s’appuie sur les Server Components, Suspense et les Server Functions. Par défaut, les composants serveur permettent de produire l’interface sans ajouter leur code au bundle JavaScript du navigateur. Les composants client restent utiles pour les formulaires, les interactions et les éléments qui dépendent des API du navigateur.

Une bonne règle consiste à commencer côté serveur, puis à déplacer vers le client seulement les composants réellement interactifs. Cette séparation réduit le JavaScript initial et simplifie l’accès aux données sensibles.

La documentation officielle de l’App Router détaille les conventions actuelles de routes, layouts, navigation et rendu.

Réduire le JavaScript envoyé au navigateur

  • limiter les composants client aux zones interactives ;
  • importer dynamiquement les modules lourds qui ne sont pas nécessaires au premier affichage ;
  • éviter les bibliothèques générales lorsqu’une fonction légère suffit ;
  • analyser régulièrement le bundle de production ;
  • charger les scripts tiers après le contenu essentiel lorsque leur usage le permet.

Un site peut sembler rapide en développement et ralentir en production à cause des outils analytics, widgets de support, lecteurs vidéo ou scripts publicitaires. Chaque script tiers doit avoir un objectif mesurable.

Optimiser images, polices et stabilité visuelle

Le composant Image de Next.js peut servir des formats modernes, adapter les dimensions à l’écran et limiter les décalages de mise en page lorsque les dimensions sont correctement déclarées. Les images héro doivent avoir une priorité explicite ; les images situées plus bas peuvent être chargées à la demande.

Pour les polices, privilégiez un nombre limité de graisses et de variantes. Le chargement local et le sous-ensemble des caractères réduisent le temps d’affichage. Réservez également l’espace nécessaire aux médias, cartes et composants asynchrones afin de protéger la stabilité visuelle.

Mettre en place une stratégie de cache

Toutes les données ne vieillissent pas au même rythme. Une page institutionnelle, une fiche produit, un tableau de bord et un flux temps réel ne doivent pas utiliser la même politique.

  1. Identifier la fréquence réelle de mise à jour.
  2. Mettre en cache les contenus stables.
  3. Revalider les pages après une publication ou une modification.
  4. Éviter les requêtes identiques répétées pendant un même rendu.
  5. Documenter les cas où une donnée doit toujours être fraîche.

La stratégie de cache doit être testée avec le comportement réel de l’application, et pas seulement avec des données de démonstration.

Travailler les Core Web Vitals

Le Largest Contentful Paint dépend souvent du visuel principal, du temps de réponse serveur et des ressources bloquantes. L’Interaction to Next Paint révèle les tâches longues et les composants trop lourds. Le Cumulative Layout Shift mesure les déplacements inattendus.

Mesurez les pages importantes sur de vrais appareils et de vraies connexions. Les outils de laboratoire aident à diagnostiquer, mais les données terrain montrent l’expérience vécue par les visiteurs.

SEO technique et accessibilité

Une page rapide doit également être compréhensible :

  • title et meta description uniques ;
  • canonical cohérent avec le sitemap ;
  • une hiérarchie de titres claire ;
  • contenu principal présent dans le HTML initial ;
  • images accompagnées d’un texte alternatif utile ;
  • navigation au clavier et contrastes lisibles ;
  • données structurées adaptées au contenu visible.

La checklist de production officielle Next.js couvre le rendu, le cache, les images, les métadonnées, les Core Web Vitals et l’analyse des bundles.

Checklist avant la mise en ligne

  1. Lancer un build de production sans erreur.
  2. Tester les routes dynamiques, erreurs 404 et redirections.
  3. Vérifier le poids JavaScript des pages stratégiques.
  4. Contrôler les images, polices et scripts tiers.
  5. Tester sur mobile et réseau contraint.
  6. Vérifier canonical, sitemap, robots et données structurées.
  7. Installer un suivi des erreurs et des performances.

Guides associés