Core Web Vitals : ce que Next.js règle et ce qu'il ne règle pas

Next.js apporte trois choses qui pèsent sur les Core Web Vitals : le rendu statique ou côté serveur, donc un HTML complet dès la première réponse ; un composant d'image qui produit les bonnes dimensions, les formats modernes et réserve la place avant le chargement ; et un découpage automatique du JavaScript par route. Il ne règle ni le poids de votre code applicatif, ni les scripts tiers, ni les polices mal servies, ni un hébergement mal choisi. Le cadre pose un bon départ, il ne fait pas le travail.

Les trois métriques, en une ligne chacune

LCP, le temps d'affichage du plus grand élément visible. Seuil de bon : sous 2,5 secondes.

INP, la réactivité aux interactions, mesurée sur l'ensemble des interactions de la visite. Seuil de bon : sous 200 millisecondes.

CLS, la stabilité visuelle, c'est-à-dire l'ampleur des déplacements d'éléments pendant le chargement. Seuil de bon : sous 0,1.

Ces seuils s'apprécient au 75e centile de vos visiteurs réels, sur vingt-huit jours glissants, pas en moyenne et pas en laboratoire. C'est le rapport Signaux web essentiels de la Search Console qui fait foi.

LCP, ce que Next.js règle

Le rendu. Une page statique est servie comme un fichier depuis un point de présence proche du visiteur. Il n'y a ni base à interroger ni code à exécuter à la demande. C'est le gain le plus important, et il est structurel.

Les images. Le composant d'image de Next.js sert des dimensions adaptées à l'affichage, dans un format moderne, et permet de marquer explicitement l'image prioritaire.

LCP, ce qui reste à votre charge

Marquer la bonne image comme prioritaire. Par défaut, les images sont chargées en différé. L'image du premier écran, qui est le plus souvent votre élément LCP, doit être exclue de ce comportement. C'est l'erreur la plus fréquente sur les sites Next.js que nous auditons : le cadre a fait ce qu'il fallait, et le développeur a laissé le comportement par défaut sur l'image qui ne devait pas l'avoir.

Les polices. Une police chargée depuis un service tiers ajoute une résolution DNS, une connexion et un fichier avant que le texte ne s'affiche. Next.js fournit un mécanisme pour servir les polices depuis votre domaine, encore faut-il l'utiliser. Et deux familles avec quatre graisses restent huit fichiers, quel que soit le cadre.

Le choix du mode de rendu. Une page rendue à la demande, qui interroge une base à chaque requête, annule l'avantage. C'est un choix de développement, pas un défaut du cadre.

L'hébergement. Une application déployée sur un serveur unique, loin des visiteurs, sans réseau de diffusion, perd l'essentiel du bénéfice.

INP, ce que Next.js règle

Le découpage du JavaScript. Chaque route ne charge que ce dont elle a besoin, au lieu d'un paquet unique pour tout le site.

Les composants serveur. Un composant rendu sur le serveur n'envoie pas son code au navigateur. Sur un site de contenu, cela peut retirer la majeure partie du JavaScript de la page.

INP, ce qui reste à votre charge

La quantité de code client que vous écrivez. C'est le facteur dominant. Un site qui rend tout côté client, par habitude ou par facilité, se prive du principal apport du cadre.

Les scripts tiers. Suivi analytique, chat, cartes, widgets d'avis, régies publicitaires. Ils s'exécutent sur le fil principal et ils sont la première cause de mauvais INP sur les sites que nous mesurons, toutes technologies confondues. Aucun cadre ne peut rien contre un script tiers mal écrit, sinon le charger plus tard ou pas du tout.

Les gestionnaires d'événements coûteux. Un écouteur de défilement qui déclenche un rendu à chaque image, une recherche qui filtre une longue liste à chaque frappe. Ce sont des problèmes d'écriture, pas de cadre.

CLS, ce que Next.js règle

Les dimensions d'image. Le composant d'image réserve la place avant le chargement, ce qui supprime la cause numéro un de décalage.

CLS, ce qui reste à votre charge

Tout ce qui s'insère après coup. Un bandeau de consentement, une bannière promotionnelle, un message d'alerte, une publicité. Chacun pousse le contenu vers le bas s'il n'a pas de place réservée.

Les polices sans repli correct. Une police qui remplace une police système au chargement change les métriques du texte et décale ce qui suit. Le mécanisme de Next.js aide, il faut encore déclarer un repli aux métriques ajustées.

Le contenu chargé après le rendu. Une liste d'avis, un carrousel de produits, une carte : tout élément dont la hauteur n'est pas réservée déplace le reste à son arrivée.

Les images qui gardent leurs proportions natives. Sur un composant qui affiche des visuels de formats variés, ne pas déclarer les dimensions revient à laisser la page sauter à chaque arrivée.

Ce qui dégrade les scores sur un site Next.js

Ce sont des erreurs que nous rencontrons régulièrement, et qui font qu'un site moderne mesure moins bien qu'un WordPress correctement mis en cache.

• Tout rendre côté client par confort, en marquant les composants comme clients à la racine de l'arbre.
• Charger une bibliothèque entière pour une fonction, sans découpage.
• Empiler les scripts tiers sans stratégie de chargement.
• Oublier la priorité sur l'image du premier écran.
• Déployer sans réseau de diffusion, sur un serveur unique.
• Ne jamais mesurer, et se fier au fait que le cadre est réputé rapide.

Comment mesurer correctement

Les données de terrain de la Search Console pour savoir si vous avez un problème. C'est la seule source qui compte, parce qu'elle vient de vos visiteurs.

PageSpeed Insights pour diagnostiquer. Le score de laboratoire varie fortement d'une exécution à l'autre : ne décidez jamais sur une mesure unique, et ne comparez jamais deux sites avec deux mesures uniques.

Une mesure en continu si le site évolue souvent. Un site qui passait les seuils il y a six mois peut ne plus les passer après trois ajouts de scripts.

Un point sur lequel nous sommes clairs en interne : notre propre moyenne Lighthouse sur les sites livrés récemment est de l'ordre de 90 en préréglage ordinateur, et de 67 en mobile. L'écart entre les deux est la norme, pas une exception, et une agence qui communique un score sans dire lequel des deux communique la moitié qui l'arrange.

Questions fréquentes

Un site Next.js est-il forcément rapide ?

Non. Il part avec de bonnes conditions et il peut être lent si tout est rendu côté client, si les scripts tiers s'accumulent ou si l'hébergement n'est pas adapté. La technologie fixe un plafond, elle ne garantit pas un plancher.

Les Core Web Vitals influencent-ils vraiment le classement ?

Ce sont des facteurs de classement, modestes comparés à la pertinence du contenu. Leur effet principal est commercial : une page lente perd des visiteurs avant qu'ils ne lisent quoi que ce soit. Optimisez pour les visiteurs, le classement suit.

Comment gérer les scripts tiers sans casser la mesure ?

Trois questions par script : est-il indispensable, peut-il être chargé après l'interaction, existe-t-il une alternative plus légère. Un outil de mesure d'audience respectueux de la vie privée pèse une fraction d'une solution complète, et se passe de bandeau de consentement, ce qui supprime au passage une cause de décalage visuel.

Quel seuil viser en pratique ?

Passer les trois seuils au 75e centile sur mobile, ce qui est plus exigeant que sur ordinateur. Viser un score de laboratoire parfait n'a aucun intérêt commercial et coûte cher en dernier dixième. La bonne cible est le vert sur les données de terrain, pas le 100 en laboratoire.

Pour aller plus loin

Si le site à améliorer est un WordPress, les causes de lenteur sont ailleurs et sont décrites dans notre article sur les sites WordPress qui ralentissent. Si la question est de savoir si le changement de technologie se justifie, elle est traitée dans l'article sur Next.js pour un site vitrine. Nous auditons les performances dans le cadre de notre page audit SEO technique.