Comment optimiser votre environnement de développement local

Next.js est conçu pour offrir une excellente expérience développeur. À mesure que votre application grandit, vous pourriez remarquer des temps de compilation plus lents lors du développement local. Ce guide vous aidera à identifier et résoudre les problèmes courants de performance lors de la compilation.

Développement local vs production

Le processus de développement avec next dev est différent de next build et next start.

next dev compile les routes de votre application au fur et à mesure que vous les ouvrez ou naviguez vers elles. Cela vous permet de démarrer le serveur de développement sans attendre que chaque route de votre application soit compilée, ce qui est à la fois plus rapide et utilise moins de mémoire. L'exécution d'une build de production applique d'autres optimisations, comme la minification des fichiers et la création de hachages de contenu, qui ne sont pas nécessaires pour le développement local.

Améliorer les performances en développement local

1. Vérifiez votre antivirus

Les logiciels antivirus peuvent ralentir l'accès aux fichiers.

Essayez d'ajouter votre dossier de projet à la liste d'exclusion de l'antivirus. Bien que cela soit plus courant sur les machines Windows, nous le recommandons pour tout système avec un outil antivirus installé.

2. Mettez à jour Next.js et activez Turbopack

Assurez-vous d'utiliser la dernière version de Next.js. Chaque nouvelle version inclut souvent des améliorations de performance.

Turbopack est un nouveau bundler intégré à Next.js qui peut améliorer les performances locales.

npm install next@latest
npm run dev --turbopack

En savoir plus sur Turbopack. Consultez nos guides de mise à niveau et codemods pour plus d'informations.

3. Vérifiez vos imports

La façon dont vous importez du code peut grandement affecter le temps de compilation et de bundling. Apprenez-en plus sur l'optimisation du bundling des packages et explorez des outils comme Dependency Cruiser ou Madge.

Bibliothèques d'icônes

Les bibliothèques comme @material-ui/icons ou react-icons peuvent importer des milliers d'icônes, même si vous n'en utilisez que quelques-unes. Essayez d'importer uniquement les icônes dont vous avez besoin :

// Au lieu de ceci :
import { Icon1, Icon2 } from 'react-icons/md'

// Faites ceci :
import Icon1 from 'react-icons/md/Icon1'
import Icon2 from 'react-icons/md/Icon2'

Les bibliothèques comme react-icons incluent de nombreux ensembles d'icônes différents. Choisissez un ensemble et restez-y.

Par exemple, si votre application utilise react-icons et importe tous ces ensembles :

pi (Phosphor Icons)
md (Material Design Icons)
tb (tabler-icons)
cg (cssgg)

Combinés, ils représenteront des dizaines de milliers de modules que le compilateur doit gérer, même si vous n'utilisez qu'une seule importation de chaque.

Fichiers "barrel"

Les "fichiers barrel" sont des fichiers qui exportent de nombreux éléments depuis d'autres fichiers. Ils peuvent ralentir les builds car le compilateur doit les analyser pour détecter s'il y a des effets de bord dans la portée du module en utilisant l'import.

Essayez d'importer directement depuis des fichiers spécifiques lorsque possible. En savoir plus sur les fichiers barrel et les optimisations intégrées dans Next.js.

Optimisez les imports de packages

Next.js peut automatiquement optimiser les imports pour certains packages. Si vous utilisez des packages qui utilisent des fichiers barrel, ajoutez-les à votre next.config.js :

module.exports = {
  experimental: {
    optimizePackageImports: ['package-name'],
  },
}

Turbopack analyse automatiquement les imports et les optimise. Il ne nécessite pas cette configuration.

4. Vérifiez votre configuration Tailwind CSS

Si vous utilisez Tailwind CSS, assurez-vous qu'il est correctement configuré.

Une erreur courante est de configurer votre tableau content de manière à inclure node_modules ou d'autres répertoires volumineux de fichiers qui ne devraient pas être analysés.

Tailwind CSS version 3.4.8 ou plus récente vous avertira des paramètres qui pourraient ralentir votre build.

Dans votre tailwind.config.js, soyez précis sur les fichiers à analyser :

module.exports = {
  content: [
    './src/**/*.{js,ts,jsx,tsx}', // Bon
    // Ceci pourrait être trop large
    // Cela correspondra aussi à `packages/**/node_modules`
    // '../../packages/**/*.{js,ts,jsx,tsx}',
  ],
}

Évitez d'analyser des fichiers inutiles :
module.exports = { content: [ // Mieux - n'analyse que le dossier 'src' '../../packages/ui/src/**/*.{js,ts,jsx,tsx}', ], }

5. Vérifiez les paramètres webpack personnalisés

Si vous avez ajouté des paramètres webpack personnalisés, ils pourraient ralentir la compilation.

Demandez-vous si vous en avez vraiment besoin pour le développement local. Vous pouvez éventuellement ne les inclure que pour les builds de production, ou explorer le passage à Turbopack et utiliser des loaders.

6. Optimisez l'utilisation de la mémoire

Si votre application est très volumineuse, elle pourrait nécessiter plus de mémoire.

En savoir plus sur l'optimisation de l'utilisation de la mémoire.

7. Composants Serveur et récupération de données

Les changements dans les Composants Serveur provoquent le re-rendu complet de la page localement pour afficher les nouveaux changements, ce qui inclut la récupération de nouvelles données pour le composant.

L'option expérimentale serverComponentsHmrCache vous permet de mettre en cache les réponses fetch dans les Composants Serveur lors des rafraîchissements Hot Module Replacement (HMR) en développement local. Cela résulte en des réponses plus rapides et des coûts réduits pour les appels d'API facturés.

En savoir plus sur l'option expérimentale.

8. Privilégiez le développement local plutôt que Docker

Si vous utilisez Docker pour le développement sur Mac ou Windows, vous pourriez rencontrer des performances significativement plus lentes par rapport à l'exécution locale de Next.js.

L'accès au système de fichiers par Docker sur Mac et Windows peut faire que le Hot Module Replacement (HMR) prend des secondes voire des minutes, alors que la même application s'exécute avec un HMR rapide en développement local.

Cette différence de performance est due à la façon dont Docker gère les opérations sur le système de fichiers en dehors des environnements Linux. Pour la meilleure expérience de développement :

Utilisez le développement local (npm run dev ou pnpm dev) plutôt que Docker pendant le développement
Réservez Docker pour les déploiements en production et les tests de builds de production
Si vous devez utiliser Docker pour le développement, envisagez d'utiliser Docker sur une machine ou VM Linux

En savoir plus sur le déploiement Docker pour un usage en production.

Outils pour identifier les problèmes

Journalisation détaillée des fetch

Utilisez l'option logging.fetches dans votre fichier next.config.js pour voir des informations plus détaillées sur ce qui se passe pendant le développement :

module.exports = {
  logging: {
    fetches: {
      fullUrl: true,
    },
  },
}

En savoir plus sur la journalisation des fetch.

Traçage Turbopack

Le traçage Turbopack est un outil qui vous aide à comprendre la performance de votre application pendant le développement local. Il fournit des informations détaillées sur le temps pris par chaque module pour compiler et comment ils sont liés.

Assurez-vous d'avoir la dernière version de Next.js installée.
Générez un fichier de trace Turbopack :
NEXT_TURBOPACK_TRACING=1 npm run dev
Naviguez dans votre application ou modifiez des fichiers pour reproduire le problème.
Arrêtez le serveur de développement Next.js.
Un fichier appelé trace-turbopack sera disponible dans le dossier .next.
Vous pouvez interpréter le fichier en utilisant next internal trace [chemin-vers-fichier] :
next internal trace .next/trace-turbopack
Sur les versions où trace n'est pas disponible, la commande s'appelait turbo-trace-server :
next internal turbo-trace-server .next/trace-turbopack
Une fois le serveur de trace démarré, vous pouvez visualiser la trace à l'adresse https://trace.nextjs.org/.
Par défaut, le visualiseur de trace agrège les timings. Pour voir chaque temps individuel, vous pouvez basculer de "Aggregated in order" à "Spans in order" en haut à droite du visualiseur.

Toujours des problèmes ?

Partagez le fichier de trace généré dans la section Traçage Turbopack sur GitHub Discussions ou Discord.

Comment optimiser votre environnement de développement local

On this page