Performance Next.js : identifier d’abord la partie lente

Diagnostiquez Next.js avec travail serveur, JavaScript client, frontières de rendu, images et mesures sur une version de production.

Une structure sombre massive évolue vers des modules plus légers sous un anneau argenté.

Une page Next.js lente peut attendre le serveur, les ressources, le JavaScript ou plusieurs de ces éléments. Commencez avec un build de production et un parcours reproductible. Le mode développement aide au débogage, mais ne constitue pas une référence fiable de production. Notez route, appareil, réseau et type de visite : premier accès, cache ou navigation dans l’application.

Séparer attente et travail du navigateur

Examinez réponse initiale et requêtes nécessaires au rendu. Suivez base de données et appels externes avant de rendre le framework responsable. Inspectez ensuite JavaScript téléchargé et activité du thread principal. Un HTML rapide peut cacher une interaction lente lorsque le composant client travaille beaucoup. Inversement, réduire le bundle ne répare pas une requête serveur bloquée sur un fournisseur. Situez d’abord le délai dans une phase mesurable, avec une trace ou une observation reproductible.

Revoir frontières et données

Tenez compte de la version Next.js et du modèle de routage pour le cache et le rendu. Ne transposez pas une règle d’une autre version sans vérifier son comportement. Gardez les frontières interactives aussi petites que raisonnable et évitez d’expédier au navigateur dépendances ou données nécessaires seulement au serveur. Examinez les chaînes sérielles et les tâches indépendantes pouvant être parallélisées. Toute modification de cache demande des attentes explicites de fraîcheur et d’invalidation, surtout pour les données personnelles.

Inspecter médias et services tiers

Vérifiez dimensions, tailles responsives et découverte des images importantes sans rendre toutes les images prioritaires.
Inspectez polices, réservations d’espace et stabilité pendant le chargement.
Analysez grosses dépendances et imports client avant remplacement ou chargement différé.
Testez séparément scripts de mesure, chat et marketing pour comprendre leur contribution.

Revalider le vrai parcours

Mesurez à nouveau le même scénario et vérifiez contenu, accessibilité, authentification et cache. Une page rapide montrant un ancien prix ou les données d’un autre utilisateur n’est pas une réussite. Comparez requêtes froides et chaudes, accès direct et navigation. Documentez changement, gain et contrainte restante. Gardez mesure originale et commit pour retrouver les régressions : un petit import peut réintroduire une grosse dépendance. Reliez la conclusion à l’expérience et au coût d’exploitation plutôt qu’à une taille de bundle isolée, puis ajoutez un contrôle adapté.

Questions fréquentes

Tous les composants doivent-ils être clients ?

Non. Réservez les frontières client à l’interactivité requise et gardez le travail serveur hors du bundle.

Le cache améliore-t-il toujours la page ?

Seulement si fraîcheur, invalidation et isolation des données restent correctes.

Peut-on mesurer en développement ?

Utilisez un build de production pour conclure sur les performances comparables.

Toutes les images doivent-elles être prioritaires ?

Non. Priorisez la ressource initiale réellement importante et chargez les autres de façon appropriée.

Que mettre dans un ticket performance ?

Parcours reproductible, référence, hypothèse causale, acceptation et mesure comparable après correction.

Transformons votre besoin en périmètre réalisable

Partagez le parcours utilisateur, les intégrations et les contraintes de lancement. Nous pouvons préparer une estimation avec hypothèses et exclusions.

Découvrir le périmètre de prestation →