Neuf façons d’accélérer les builds de développement et les bundles en production avec Next.js

Next.js vous offre du routage, du rendu serveur, des routes API et une optimisation des images en complément de React, avec presque aucune configuration nécessaire, ce qui explique pourquoi il est si souvent choisi, y compris pour les projets générés par l’IA. Cependant, à mesure que le projet grandit, les mêmes problèmes apparaissent : les compilations ralentissent, le remplacement en temps réel des modules est lent, et même une petite modification de l’interface semble prendre du temps. Une compilation qui dure dix secondes au lieu d’une seconde peut représenter des heures par mois, et devoir attendre qu’un assistant IA applique une modification pendant que la page se recompile est particulièrement agaçant.

Permettre à un assistant IA d’auditer le projet

Avec un éditeur de code basé sur l’IA, vous n’avez pas besoin d’appliquer chaque conseil manuellement. Demandez à l’assistant de comparer la base de code avec les pratiques indiquées ci-dessous. Une demande utile consiste à lui demander de vérifier chaque pratique, d’expliquer pourquoi elle est importante, d’estimer son impact sur la vitesse de développement, le temps de compilation ou de exécution, d’afficher les modifications de code exactes, et de confirmer tout cela par rapport à la documentation officielle actuelle de Next.js et React. Il doit signaler les conseils devenus obsolètes ou dépréciés et proposer plutôt une approche plus récente, sans effectuer d’optimisations spéculatives non soutenues par la documentation ou inadaptées au projet.

Vérifiez tout ce qu’il génère avant de fusionner les modifications. Les frameworks évoluent rapidement, et ce qui était utile il y a un an peut être irrelevant aujourd’hui. Traitez l’assistant comme un réviseur expérimenté, et non comme une source infaillible. La documentation officielle ainsi que les besoins de l’application spécifique sont déterminants pour la décision finale.

Neuf habitudes qui rapportent

1. Exécuter le développement avec Turbopack

Dans les versions récentes de Next.js, Turbopack est stable pour le développement local. Son activation se fait via un paramètre :

next dev --turbopack

Lorsque l’ancien serveur de développement basé sur Webpack traite une grande partie du projet, Turbopack ne recompile que les modules qui ont changé. Dans les projets de taille moyenne et grande, le démarrage ainsi que le HMR s’améliorent immédiatement. Les builds en production utilisent toujours le pipeline standard, donc son utilisation en développement présente peu de risques.

2. Précompiler les dépendances lourdes

Le retraitement des paquets tiers qui changent rarement à chaque démarrage est une cause majeure de lents débuts. Material UI, Monaco Editor, Three.js, Chart.js ainsi que de grands ensembles d’icônes sont coûteux à gérer à chaque fois que le serveur de développement démarre. Next.js peut optimiser les imports pour les paquets nommés :

experimental: {
    optimizePackageImports: [
        "@mui/material",
        "@mui/icons-material",
        "lodash"
    ]
}

Évitez également d’importer un ensemble complet lorsque l’utilitaire nécessaire suffit. Un graphe de dépendances plus petit se compile plus rapidement.

3. Omettre les fichiers barrel

Un seul index.ts qui réexporte chaque composant donne un aspect ordonné aux imports, mais il oblige le compilateur à parcourir bien plus de fichiers que nécessaire. Cet import passe par le fichier barrel :

import { Button } from "@/components";

Il est préférable d’importer depuis le chemin propre au composant :

import Button from "@/components/Button";

C’est une modification mineure qui réduit la résolution des modules, en particulier dans les applications plus volumineuses.

4. Éviter les vérifications de type sur le serveur de développement

De nombreux développeurs bloquent leur serveur de développement pour les vérifications TypeScript que l’éditeur effectue déjà. Lancez le serveur ainsi qu’un surveillant TypeScript en tant que deux processus distincts :

next dev --turbopack
tsc --watch

La page se recharge instantanément, et les erreurs de frappe apparaissent toujours en temps réel.

5. Gardez les composants clients petits

Dans App Router, tout fichier marqué "use client" finit dans le bundle du navigateur. Demandez-vous si un composant a vraiment besoin d’un rendu côté client. Les layouts statiques, la navigation, les pages de contenu et le chargement des données peuvent souvent rester des composants serveur, tandis que les composants clients sont réservés aux parties nécessitant réellement une interactivité. Cela envoie moins de JavaScript au navigateur et signifie également moins de modules clients à recompiler pendant le développement.

6. Chargez les bibliothèques lourdes sur demande

Une dépendance qui n’est pas nécessaire dès la première affichage peut attendre. Les éditeurs, les visualiseurs PDF, les cartes, ainsi que les packages de graphiques et de visualisation sont de bons candidats pour être chargés de manière différée, uniquement lorsque quelqu’un y accède :

const Editor = dynamic(() => import("./Editor"), {
    ssr: false
});

Tant le paquet initial que les recompilations en mode développement restent nettement plus petits.

7. Diviser les composants volumineux

Les composants de page géants ralentissent tout le monde. Une page contenant des centaines de lignes de JSX est mieux divisée en parties plus petites et réutilisables, que le compilateur peut mettre en cache plus facilement, qui sont plus simples à tester et se recompilent plus rapidement lorsqu’il y a des changements. Si un fichier devient difficile à naviguer, c’est généralement le signe qu’il faut le diviser.

8. Désactiver les services inutiles en développement

Les outils d’analyse, les plateformes de journalisation, la répétition des sessions, les SDK de surveillance et les scripts marketing sont importants en production et ne sont que rarement utiles lors du développement de fonctionnalités. Démarrez-les uniquement lorsque vous exécutez en production :

if (process.env.NODE_ENV === "production") {
    initializeAnalytics();
    initializePWA();
}

Une initialisation réduite signifie un démarrage local plus propre et aucune requête réseau externe pendant le développement.

9. Ajustez également la compilation en production

La vitesse de développement n’est qu’une partie du tableau. Utilisez le composant Image de Next.js à la place des balises d’image brutes, cachez autant que possible, compressez les ressources et comptez sur les composants serveur pour réduire la quantité de JavaScript livrée. Vérifiez régulièrement le bundle avec un analyseur de bundle afin de détecter tôt d’éventuelles dépendances excessivement volumineuses. De nombreuses petites améliorations au fil du temps valent généralement mieux qu’une seule grande optimisation à la fin.

Où commencer

L’objectif est de comprendre où passe réellement le temps, que ce soit pendant le développement, lors de la compilation ou en temps de exécution. Commencez par les fondamentaux : un graphe de dépendances bien organisé, un découpage du code réfléchi, un minimum de JavaScript côté client et les outils déjà fournis par Next.js. Mesurez ce qui change, itérez et réexaminez l’architecture à mesure que l’application se développe.

Next.js continue d’évoluer, et les recommandations changent à chaque nouvelle version. Que ces modifications proviennent de vous ou d’un assistant IA, vérifiez-les d’abord contre les derniers documents officiels de Next.js et React. La meilleure optimisation est celle qui convient à la version sur laquelle vous travaillez actuellement, et non celle qui était populaire l’année dernière.