Pourquoi votre site Next.js est lent et comment y remédier

Next.js a été créé pour résoudre les problèmes de performance qui affectaient les premières applications React : écrans blancs, bundles client gigantesques et référencement SEO faible dû au rendu exclusivement côté client. Le rendu côté serveur (SSR), la génération statique (SSG), le découpage automatique du code et le modèle de streaming de l'App Router existent tous spécifiquement pour accélérer le chargement des pages.

Rien de tout cela ne se produit automatiquement dès qu'un projet dépasse le stade de la démonstration. Ajoutez suffisamment de composants client, de scripts tiers et d'images non optimisées, et un site Next.js régresse vers les problèmes exacts qu'il était censé éviter. Le framework fournit la capacité ; la qualité de l'implémentation détermine le résultat.

Avant de corriger quoi que ce soit, confirmez ce qui est réellement défaillant. « Semble lent » et « mesurablement lent » sont deux problèmes différents qui nécessitent des outils distincts.

Google mesure la vitesse des sites et l'expérience utilisateur à travers trois Core Web Vitals : Largest Contentful Paint (LCP), Interaction to Next Paint (INP) et Cumulative Layout Shift (CLS). Le LCP mesure le temps nécessaire pour afficher le plus grand élément visible (généralement une image principale ou un titre). L'INP mesure la réactivité de la page lors de chaque clic, appui et pression de touche pendant la visite. Le CLS mesure le décalage inattendu du contenu pendant le chargement de la page.

Google évalue ces seuils au 75e percentile des sessions de visiteurs réels sur une fenêtre glissante de 28 jours, à l'aide des données de terrain du Chrome UX Report (CrUX), et non lors d'un test unique en environnement de développement. Une page peut sembler rapide dans Lighthouse et échouer dans le monde réel si une part significative des visiteurs sur téléphones anciens ou connexions lentes subit une expérience dégradée.

Les outils incontournables :

• [Google PageSpeed Insights](https://pagespeed.web.dev/) : Combine les données de terrain (CrUX) et de laboratoire (Lighthouse) pour mobile et ordinateur.
• [Rapport Core Web Vitals de Search Console](https://support.google.com/webmasters/answer/9205520) : Affiche le statut réel de réussite/échec par groupe d'URL.
• Panneau Performance de Chrome DevTools : Pour cibler les goulots d'étranglement spécifiques pendant le développement.
• WebPageTest : Analyse en cascade approfondie, utile pour diagnostiquer le TTFB et les ressources bloquant le rendu.
• Vercel Analytics ou outils RUM : Pour la surveillance continue des utilisateurs réels plutôt que des mesures ponctuelles.

Les données de laboratoire indiquent ce qui ne va pas dans un test contrôlé. Les données de terrain montrent ce que vivent vos utilisateurs réels. Les équipes qui ne consultent que Lighthouse manquent systématiquement les utilisateurs mobiles et à faible bande passante qui rencontrent des difficultés réelles ; utilisez les deux.

Une fois le diagnostic confirmé, la solution dépend de la cause fondamentale parmi les six identifiées. La plupart des sites Next.js lents présentent plusieurs causes simultanées :

1. Une stratégie de rendu inadaptée au contenu

Next.js prend en charge plusieurs stratégies de rendu, et choisir la mauvaise pour une page donnée constitue l'une des erreurs les plus courantes et les plus coûteuses que nous observons.

Un tableau de bord rendu en SSR à chaque requête sera toujours plus lent que nécessaire si les données sous-jacentes ne changent qu'une fois par heure. Passez ce tableau de bord en ISR, et le TTFB chutera drastiquement sans perdre la fraîcheur du contenu. Consultez notre guide d'architecture CMS headless pour approfondir les modèles de rendu.

2. Une surcharge d'hydratation côté client

L'hydratation est le processus par lequel React attache l'interactivité au HTML statique déjà envoyé par le serveur. Tant que l'hydratation n'est pas terminée, les boutons semblent cliquables mais ne le sont pas. Sur les pages chargées en JavaScript comportant des dizaines de composants client, ce délai devient perceptible et nuit lourdement à l'INP.

Les React Server Components, introduits avec l'App Router, réduisent ce problème en conservant les parties non interactives d'une page exclusivement sur le serveur. Une page remplie de composants client qui n'ont pas réellement besoin d'interactivité paie une taxe d'hydratation inutile.

3. Des bundles JavaScript surdimensionnés

Chaque importation inutile, bibliothèque non utilisée et dépendance dupliquée ajoute du poids que le navigateur doit télécharger, analyser et exécuter avant que la page ne devienne utilisable. Coupables fréquents : importer une bibliothèque d'icônes entière pour seulement trois icônes, inclure une lourde bibliothèque de dates alors que le formatage natif Intl suffirait, et envoyer du code d'administration à tous les visiteurs.

Le découpage de code et les importations dynamiques (`next/dynamic`) permettent à un composant lourd (une modale, un graphique, un éditeur de texte riche) de ne se charger que lorsqu'il est réellement nécessaire, plutôt lors du chargement initial. `@next/bundle-analyzer` permet de visualiser exactement ce qui alourdit le bundle avant de décider quoi couper.

4. Des images et polices non optimisées

Les images restent l'élément le plus lourd sur la majorité des pages web, et Next.js intègre le composant `next/image` conçu spécifiquement pour cela : redimensionnement automatique, chargement différé et conversion vers des formats modernes comme WebP ou AVIF. L'inconvénient est qu'il ne fonctionne que s'il est utilisé correctement. L'absence de la propriété `priority` sur les images principales au-dessus de la ligne de flottaison, l'absence de dimensions explicites (`width` et `height`) provoquant des décalages de mise en page, et les images servies depuis des sources externes non optimisées annulent les bénéfices de l'outil. Pour des techniques d'images avancées, lisez notre guide sur les 7 techniques pratiques pour améliorer le LCP dans Next.js.

Les polices posent un problème similaire. Sans stratégie de chargement définie, les polices personnalisées créent un flash de texte non stylisé ou invisible pendant leur chargement, nuisant au CLS et à la vitesse perçue. `next/font` héberge et précharge automatiquement les fichiers de polices, éliminant la requête bloquante vers des fournisseurs tiers.

5. Un temps de réponse serveur (TTFB) lent et un manque de mise en cache

Le TTFB mesure le temps que met le serveur à répondre avant que le navigateur ne puisse commencer le rendu. Un TTFB lent dégrade toutes les métriques en aval : un LCP médiocre de cinq secondes est souvent le symptôme d'un temps de réponse serveur de deux secondes, et non d'un problème front-end.

Les causes fréquentes incluent les requêtes SSR non mises en cache, les démarrages à froid des fonctions serverless, l'absence de cache CDN en bordure de réseau (Edge) et les requêtes de base de données exécutées de manière synchrone à chaque chargement. Des en-têtes `Cache-Control` appropriés, une mise en cache CDN (via le réseau Edge de Vercel ou Cloudflare) et le déplacement des traitements lourds hors du chemin de la requête grâce à l'ISR ou à des tâches en arrière-plan résolvent la plupart de ces problèmes.

6. Des scripts tiers et requêtes de base de données non optimisés

Les pixels d'analyse, widgets de chat, balises publicitaires et outils marketing ajoutent leur propre JavaScript, et chacun entre en compétition avec le code du site pour le thread principal. Une page peut disposer d'un code parfaitement optimisé et échouer à l'INP parce qu'un script tiers non optimisé bloque l'interaction pendant une demi-seconde.

Côté backend, les problèmes de requêtes N+1 et l'absence d'index de base de données ralentissent les routes SSR et API même si le front-end est bien conçu. Si une page interroge la base de données dix fois pour afficher une liste, aucune optimisation front-end ne pourra régler le problème : le correctif doit intervenir au niveau de l'ORM ou de la requête.

Migrer vers l'App Router seul ne garantit pas un site plus rapide, même si cette idée reçue est fréquente. Les véritables avantages de performance de l'App Router (React Server Components, streaming et mise en cache plus fine) ne se manifestent que lorsqu'ils sont exploités volontairement. Un projet qui change de router mais conserve la directive « use client » sur chaque composant garde exactement la même surcharge d'hydratation qu'auparavant, simplement enveloppée dans une syntaxe plus récente.

Le router importe moins que les choix d'architecture effectués en son sein.

Chez Belk Digital, nous suivons une méthodologie systématique de correction en 7 étapes pour maîtriser la vitesse des sites :

1. Établir le bilan de l'état actuel : Exécuter PageSpeed Insights et consulter le rapport Core Web Vitals de Search Console pour obtenir des données de terrain réelles avant de modifier le moindre code.
2. Identifier le goulot d'étranglement principal : TTFB, taille du bundle, hydratation, images ou combinaison de facteurs. Corriger le mauvais élément en premier fait perdre un sprint entier.
3. Optimiser le temps de réponse serveur en priorité : Les ajustements de stratégie de rendu et de mise en cache offrent généralement la plus forte amélioration, car tout le reste en dépend.
4. Optimiser les images et les polices : Ce sont généralement les gains les plus rapides avec le moins de risques de régression sur la page.
5. Réduire et découper le bundle JavaScript : Auditer les dépendances, convertir les composants client inutiles en composants serveur et ajouter des importations dynamiques pour les éléments UI lourds non critiques.
6. Auditer les scripts tiers : Différer, charger tardivement ou supprimer les scripts qui n'apportent pas une valeur proportionnelle à leur poids.
7. Re-tester et mettre en place une surveillance continue : Un correctif ponctuel se dégrade au fil du déploiement de nouvelles fonctionnalités ; le RUM détecte les régressions avant que les utilisateurs ne les signalent.

Les équipes disposant de ressources d'ingénierie internes peuvent généralement gérer l'optimisation des images, le chargement des polices et le nettoyage de base des bundles sans aide extérieure ; ce sont des correctifs bien documentés et à faible risque. En revanche, les changements de stratégie de rendu, les migrations App Router et l'optimisation des requêtes en base de données comportent plus de risques, car ils touchent à l'architecture plutôt qu'à des composants isolés, et une mauvaise décision peut introduire de nouveaux bugs tout en cherchant à gagner en vitesse.

Si un site reste lent depuis des mois malgré des tentatives internes, ou si la résolution exige de repenser la circulation des données dans l'application, un audit externe constitue généralement la voie la plus rapide et la plus économique. Pour obtenir des conseils sur les tarifs et l'évaluation avant de prendre cette décision, consultez notre guide sur comment choisir le bon partenaire digital.

La vitesse d'un site ne reste pas cantonnée à l'onglet DevTools. Les Core Web Vitals sont un signal de classement Google confirmé, et les pages lentes ou instables ont tendance à enregistrer des taux de rebond plus élevés et un engagement plus faible que les pages qui valident les trois métriques avec marge. Google a documenté des études de cas de e-commerçants ayant amélioré leurs scores Core Web Vitals tout en constatant des gains mesurables en revenus publicitaires, durée de session et trafic organique — bien que les résultats varient selon les sites et ne doivent pas être considérés comme une formule magique.

L'élément essentiel est que le travail sur les performances se cumule directement avec les efforts de SEO, d'UX et de conversion détaillés dans notre article sur comment la performance d'un site web impacte le chiffre d'affaires. Traiter la vitesse comme un projet technique ponctuel, au lieu d'une discipline continue, est la raison principale pour laquelle un site réparé se dégrade à nouveau six mois plus tard.