Performance Next.js : 9 pratiques pour garder des Core Web Vitals au vert

Pourquoi la performance Next.js compte-t-elle pour le SEO et le chiffre d'affaires ?

La performance est une fonctionnalité produit. Les Core Web Vitals font partie des signaux d'expérience de page de Google, et les pages lentes perdent leurs visiteurs avant qu'ils ne lisent un mot. Quand le Largest Contentful Paint dérape ou que la mise en page saute sous le pouce de l'utilisateur, la conversion et la confiance en pâtissent, même si la logique métier est parfaite.

Next.js offre d'excellents réglages par défaut, mais ils ne résistent pas toujours au contenu réel, aux scripts tiers et aux demandes marketing. Voici les neuf pratiques que notre équipe de développement web applique sur chaque projet pour garder les sites rapides après la mise en ligne.

Quels sont les seuils des Core Web Vitals ?

Google évalue trois métriques à partir des données terrain des utilisateurs réels de Chrome, au 75e percentile des chargements de page :

• Largest Contentful Paint (LCP) : la vitesse d'affichage du contenu principal. Bon : 2,5 secondes ou moins.
• Interaction to Next Paint (INP) : la rapidité de réaction de la page aux touchers, clics et frappes. Bon : 200 millisecondes ou moins. L'INP a remplacé le First Input Delay en mars 2024.
• Cumulative Layout Shift (CLS) : l'ampleur des déplacements inattendus du contenu visible. Bon : 0,1 ou moins.

1. Rendre le premier écran côté serveur

Avec l'App Router, les composants sont des React Server Components par défaut. Ils sont rendus en HTML sur le serveur et n'envoient aucun JavaScript pour leur propre code. Nous gardons les îlots interactifs, comme un menu ou un formulaire, sous forme de petits composants client, et nous chargeons les données côté serveur pour que le premier écran n'attende jamais une cascade de requêtes côté client.

Pour les données plus lentes, nous utilisons le streaming : la structure de la page et le contenu au-dessus de la ligne de flottaison arrivent d'abord, puis une frontière Suspense complète le reste. L'utilisateur voit rapidement un contenu utile au lieu d'un écran vide.

2. Traiter les images comme un budget de performance

L'élément LCP est généralement une image d'en-tête ou un titre. Nous utilisons next/image pour que chaque image ait des sizes corrects, des formats modernes comme AVIF ou WebP, et un chargement différé sous la ligne de flottaison.

• Ne donnez la priorité qu'à l'image LCP. Tout prioriser revient à ne rien prioriser.
• Indiquez toujours largeur et hauteur (ou un ratio fixe) pour que le navigateur réserve l'espace et que le CLS reste proche de zéro.
• Gardez les dégradés décoratifs en CSS ou en SVG inline pour qu'ils ne bloquent jamais le rendu.

3. Auto-héberger les polices avec next/font

Les polices chargées depuis une feuille de style tierce ajoutent des requêtes DNS et provoquent souvent un clignotement ou un décalage du texte. next/font télécharge les polices au moment du build, les sert depuis votre propre domaine et génère des métriques de repli qui limitent les décalages. Pour un site multilingue, ne conservez que les jeux de caractères réellement utilisés, par exemple latin et arabe.

4. Envoyer moins de JavaScript pour protéger l'INP

L'INP se dégrade quand le thread principal est occupé. Les plus gros gains viennent de l'envoi de moins de code : déplacer la logique dans les Server Components, importer dynamiquement les widgets lourds et auditer les dépendances avec un analyseur de bundle. Nous trouvons régulièrement des bibliothèques de dates, d'icônes ou de graphiques qui embarquent bien plus de code que nécessaire.

Pour les interactions qui déclenchent des mises à jour coûteuses, nous utilisons useTransition afin de garder l'interface réactive, et nous découpons les tâches longues.

5. Maîtriser les scripts tiers

Analytics, widgets de chat et gestionnaires de balises sont des causes fréquentes de mauvais INP. Chargez-les avec next/script et la stratégie afterInteractive ou lazyOnload, supprimez les balises inutilisées et questionnez chaque nouveau script en revue de code. Nos configurations SEO et analytics utilisent un suivi léger qui respecte le consentement sans ralentir la page.

6. Mettre en cache avec intention

La plupart des pages marketing et de contenu peuvent être statiques. Pour les contenus qui évoluent, nous choisissons des frontières de cache explicites :

• Revalidation temporelle pour les données qui peuvent dater de quelques minutes, comme les listes d'articles ou les catalogues.
• Revalidation à la demande avec revalidateTag ou revalidatePath lorsqu'un éditeur publie, pour que les mises à jour apparaissent immédiatement sans reconstruire le site.
• Rendu dynamique uniquement pour les pages vraiment personnalisées, comme les tableaux de bord ou les paniers.

Associez cela à un CDN et à des en-têtes de cache corrects. Notre équipe cloud et DevOps dimensionne l'hébergement pour que le réseau edge serve l'essentiel du trafic.

7. Concevoir pour la stabilité de la mise en page

Le CLS est souvent un problème de design plus que de code. Bandeaux cookies qui poussent le contenu, publicités sans emplacement réservé et polices chargées tardivement sont les coupables habituels. Nos designers UI/UX prévoient des squelettes et des dimensions fixes pour chaque zone dynamique afin que la page soit stable dès le premier affichage.

8. Surveiller les utilisateurs réels, pas seulement le laboratoire

Les tests synthétiques détectent les déploiements cassés ; le suivi des utilisateurs réels montre ce que ressentent vos clients sur des téléphones de milieu de gamme et des réseaux mobiles. Nous remontons les Web Vitals depuis le navigateur avec le hook useReportWebVitals et déclenchons une alerte quand le 75e percentile franchit un seuil.

9. Intégrer la performance au processus de livraison

La performance s'érode une fonctionnalité à la fois. Nous ajoutons des contrôles de taille de bundle et Lighthouse à la CI, revoyons les Web Vitals lors des démos de sprint et incluons une revue de performance dans nos offres de maintenance et support. Le même état d'esprit d'observabilité s'applique aux fonctionnalités d'IA, comme nous l'expliquons dans passer l'IA du pilote à la production.

Vous préparez un lancement à fort trafic ou une migration ? Nous pouvons auditer vos routes, votre bundle et votre configuration CDN, puis livrer un backlog priorisé. Contactez-nous pour planifier un audit.