Optimisation des performances Next.js : le guide complet

Q: Qu'est-ce qu'un bon score Lighthouse pour un site Next.js ?

Tout ce qui dépasse 90 est considéré comme bon, au-dessus de 95 comme très bon. Nos projets atteignent régulièrement 95–100. Un score inférieur à 70 indique des problèmes de performance structurels, corrigeables par une optimisation ciblée.

Q: Pourquoi mon site Next.js est-il lent bien que j'utilise Next.js ?

Next.js ne garantit pas la performance — des implémentations incorrectes peuvent anéantir les avantages. Causes fréquentes : flags priority manquants sur les images, trop de client components au lieu de server components, scripts externes bloquant le rendu, requêtes base de données médiocres en SSR.

Q: Combien de temps dure un audit de performance ?

Un audit de performance de base avec recommandations d'amélioration dure 2 à 4 heures. Un audit complet avec mise en œuvre des améliorations prend 1 à 5 jours selon la taille du projet.

Q: La performance améliore-t-elle réellement le taux de conversion ?

Oui, de nombreuses études le prouvent. Google et Amazon l'ont montré : 100 ms de temps de chargement supplémentaires signifient 1 % de conversions en moins. Une page qui se charge 1 seconde plus vite convertit typiquement 2 à 5 % mieux.

Q: Combien coûte une optimisation de performance Next.js ?

Un audit de performance coûte 490–990 €. La mise en œuvre des améliorations identifiées dépend du périmètre : 1.000–5.000 € pour des projets typiques. Souvent, 20 % des mesures sont responsables de 80 % du gain de performance.

Wito AI

Guide performance11 min de lecture

Guide performance

Performance Next.js Atteindre Lighthouse 95+

Techniques concrètes pour des performances Next.js maximales : LCP sous 1 seconde, CLS proche de zéro, INP sous 50 ms. Grâce à ces méthodes, nos projets atteignent durablement des scores Lighthouse supérieurs à 95.

Comprendre les Core Web Vitals

Les Core Web Vitals de Google sont les indicateurs de performance décisifs pour le SEO et l'expérience utilisateur : LCP (Largest Contentful Paint) : combien de temps faut-il pour que le plus grand élément visible de la page soit chargé ? Objectif : moins de 2,5 secondes, idéalement moins de 1 seconde. INP (Interaction to Next Paint) : à quelle vitesse la page réagit-elle aux interactions de l'utilisateur ? Objectif : moins de 200 ms, idéalement moins de 50 ms. CLS (Cumulative Layout Shift) : dans quelle mesure les éléments se déplacent-ils pendant le chargement ? Objectif : moins de 0,1, idéalement 0,02 ou moins. Next.js offre nativement de meilleures conditions pour ces trois métriques que WordPress ou les SPA classiques, mais des implémentations incorrectes peuvent anéantir ces avantages.

Google utilise les Core Web Vitals comme facteur de classement. Les pages aux bons vitals se classent en moyenne 15 à 25 % mieux que des pages comparables aux vitals médiocres.

Optimisation des images avec next/image

Les images sont le principal tueur de LCP. Next.js `` résout la plupart des problèmes automatiquement : Conversion WebP/AVIF automatique : Next.js livre les images dans le meilleur format pris en charge par le navigateur. AVIF est 40 à 60 % plus léger que JPEG à qualité équivalente. Lazy loading : les images situées sous la fenêtre d'affichage ne se chargent que lorsque l'utilisateur fait défiler. Définit `loading="lazy"` correctement. Flag priority pour les images LCP : l'image principale (souvent l'image hero) doit avoir `priority` afin d'être chargée tôt. L'absence de ce flag est une cause fréquente de mauvais LCP. Dimensions fixes : toujours définir `width` et `height` pour éviter le CLS causé par des images chargées tardivement. Placeholder flou : `placeholder="blur"` affiche un placeholder flou pendant le chargement et empêche les sauts visuels.

Erreur fréquente : l'image hero sans flag priority. Ajoutez priority à toutes les images above-the-fold — cela améliore souvent le LCP de 0,5 à 1,5 seconde.

Choisir la bonne stratégie de rendu

Next.js propose plusieurs modes de rendu — un mauvais choix coûte en performance : Static Generation (SSG) : les pages sont rendues au moment du build et livrées sous forme de fichiers HTML statiques. Temps de chargement le plus rapide possible. Convient aux pages qui changent rarement (landing pages, articles de blog). Incremental Static Regeneration (ISR) : les pages statiques sont rafraîchies en arrière-plan. Idéal pour les pages qui changent occasionnellement (pages produit, actualités). Le paramètre `revalidate` pilote la fréquence de mise à jour. Server-Side Rendering (SSR) : les pages sont rendues à chaque requête. Nécessaire pour des contenus personnalisés, mais plus lent. Attention : utiliser SSR pour tout est une erreur de performance courante. React Server Components (RSC) : avec l'App Router, les composants peuvent être rendus côté serveur — sans envoyer de JavaScript au client. Réduit la taille du bundle et améliore l'INP.

Des problèmes de performance dans votre projet Next.js ?

Optimiser les polices et les scripts externes

next/font pour Google Fonts N'intégrez jamais Google Fonts directement via CDN. `next/font/google` charge les polices en local et élimine la requête réseau vers les serveurs de Google — économise 200 à 500 ms et améliore la protection des données. next/script pour les scripts externes Analytics, widgets de chat, outils de test A/B — intégrez-les tous avec `