Core Web Vitals sur Next.js : ce qui casse vraiment LCP, INP et CLS

Les Core Web Vitals ne sont pas un concours de score. Ce sont trois indicateurs qui décrivent une expérience utilisateur : quand le contenu principal devient visible (LCP), quand l’interface répond à une interaction (INP), et à quel point la mise en page saute pendant le chargement (CLS). Google documente ces métriques sur web.dev ; leur définition évolue, mais la logique métier reste stable : un utilisateur qui attend, qui clique dans le vide ou qui voit le bouton bouger sous son doigt perd confiance.

Sur Next.js, le framework vous donne des leviers (SSR, streaming, Image, Font, edge), pas une immunité. Une page App Router peut être aussi lente qu’un monolithe WordPress si vous hydratez toute l’UI, chargez des polices comme en 2018 et laissez le marketing coller un pixel tag sans garde-fou. L’erreur classique de cadrage consiste à demander « un score 100 » au lieu de demander « un LCP acceptable sur les URLs qui convertissent, mesuré en terrain ».

Pour un product owner, la bonne question n’est pas « est-ce que Next.js est plus rapide ? ». C’est « quelles pages du parcours critique échouent, sur quel device, et quel chantier débloque le plus de friction ? ». Pour un développeur, la bonne question n’est pas « quel plugin magique ? ». C’est « quelle ressource bloque le paint, quel JS bloque le main thread, quel layout n’a pas de dimensions réservées ? ».

Gardez aussi la lucidité SEO : améliorer les Core Web Vitals peut soutenir l’expérience et, indirectement, la qualité perçue du site. Cela ne remplace ni le contenu, ni les redirections, ni l’autorité. Toute promesse de position garantie est hors sujet ici et hors éthique éditoriale Cosmos.

Sans mesure fiable, vous optimisez au feeling. Commencez par lister trois à cinq URL critiques : accueil, page offre, fiche mission ou produit, formulaire de contact, éventuellement une page blog à fort trafic. Pour chacune, collectez un état lab (Lighthouse ou PageSpeed Insights en mode lab) et un état terrain si disponible (CrUX via PageSpeed, rapport Core Web Vitals dans Search Console, Vercel Speed Insights).

Le lab sert à reproduire et à isoler. Le terrain sert à décider. Si le lab est médiocre et le terrain aussi, vous avez un problème structurel. Si le lab est bon et le terrain mauvais, cherchez la variance : cache froid, 3G, scripts consentement, A/B test, image hero différente selon campagne. Si le terrain est bon malgré un lab moyen, ne brûlez pas le sprint pour un score cosmétique.

Sur Next.js déployé sur Vercel, Speed Insights et Web Analytics (lorsqu’ils sont activés et consentis) donnent une lecture de terrain utile en parallèle de Search Console. Ne multipliez pas les outils au point de ne plus savoir quelle source tranche. Choisissez une source de vérité pour le backlog, et une source de diagnostic pour le debug.

Documentez la méthode dans le ticket : device (mobile d’abord), conditions réseau, URL exacte, date, capture des trois métriques, hypothèse. Sans cette hygiène, l’équipe compare des mesures incomparables et « corrige » des symptômes déjà partis.

Le LCP pointe presque toujours vers un élément visible important : image hero, bloc titre, grande section colorée. Sur les sites Agence Cosmos et sur beaucoup de vitrines B2B, le coupable numéro un reste l’image au-dessus de la ligne de flottaison. Un fichier trop lourd, un format inadapté, des dimensions absentes, un lazy-load mal placé sur le LCP candidate, ou un CDN qui sert encore un JPEG non redimensionné : le paint attend.

Next.js Image (next/image) n’est pas une baguette. Il faut lui donner des tailles réalistes, un priority sur le vrai LCP, et éviter de charger trois variantes décoratives avant le contenu utile. Servez des formats modernes quand le navigateur le permet, et ne transformez pas chaque illustration marketing en fond full-bleed 4K. La documentation officielle Next.js sur l’optimisation d’images reste la référence pour les props et les patterns App Router.

Deuxième grand coupable : les polices. Une display font bloquante, chargée via @import CSS ou lien tiers sans stratégie, retarde le texte LCP. Préférez next/font pour auto-héberger et contrôler le swap. Définissez des fallbacks métriquement proches pour limiter le décalage visuel. Une police « premium » qui arrive 1,5 s trop tard n’est plus premium : elle est juste lente.

Troisième famille : le JavaScript avant le contenu. Un layout qui attend l’hydratation d’un mega-composant client pour afficher le hero transforme Next.js en SPA coûteuse. Rendez le hero en Server Component autant que possible. Réservez « use client » aux zones interactives sous la ligne de flottaison ou réellement nécessaires au premier geste. Streaming et Suspense aident, mais ils ne sauvent pas une page qui télécharge 400 ko de JS inutile avant le premier paint utile.

Côté produit, refusez le réflexe « on mettra une vidéo autoplay en hero pour impressionner ». Une vidéo non maîtrisée est souvent un LCP et un INP en même temps. Si le storytelling l’exige, prévoyez poster image optimisée, chargement différé, et budget de poids écrit dans le brief.

L’INP (Interaction to Next Paint) a remplacé le FID comme vital d’interactivité. Il regarde la latence entre une interaction (clic, tap, clavier) et le prochain paint qui reflète la réponse. Sur Next.js, les mauvaises surprises viennent souvent d’une hydratation massive : tout le tree est « use client », des libs UI lourdes démarrent au premier écran, des listeners globaux tourment le main thread.

Réduisez la surface client. Un menu, un consentement cookies, un tracker, un chat, un A/B test : chacun ajoute du travail au thread principal. Demandez-vous si le composant doit être interactif immédiatement ou s’il peut être chargé après hydration partielle, après idle, ou après geste utilisateur. Le pattern « island » (îlot client dans une page serveur) n’est pas un slogan : c’est la façon concrète de protéger l’INP.

Les scripts tiers sont le second angle mort. Tag manager, pixels pubs, heatmaps, widgets calendrier : ils arrivent souvent après un « on verra plus tard » produit. Plus tard, l’INP mobile est déjà rouge. Négociez un budget : quels tags sont indispensables au lancement, lesquels passent après consentement, lesquels sont retirés. Chargez-les de façon différée et conditionnelle ; ne les injectez pas dans le layout racine « pour simplifier ».

Côté React, méfiez-vous des re-renders coûteux sur des gestes simples (ouvrir un menu, taper dans un champ). Un état global trop large, des contextes qui invalidient toute la page, des animations JS sur le scroll principal : tout cela se paie en INP. Préférez CSS ou des animations composées hors du chemin critique quand c’est possible. Si vous utilisez GSAP ou du canvas, isolez-les et respectez prefers-reduced-motion.

En recette, testez sur un milieu de gamme Android, pas seulement sur un MacBook. L’INP qui « passe » sur desktop puissant peut échouer sur le device de votre client PME. Notez le geste testé (ouvrir filtre, soumettre form, ouvrir menu) : une moyenne globale sans scénario ne guide personne.

Le CLS mesure l’instabilité visuelle. L’utilisateur lit, le bloc bascule, le CTA glisse : frustration immédiate. Sur Next.js, les causes fréquentes sont banales : images sans width/height ni aspect-ratio, polices qui swapent avec des métriques très différentes, bannières cookies qui poussent le contenu, embeds (vidéo, carte, feed) injectés sans skeleton.

Pour les images et médias, réservez l’espace dès le HTML/CSS. next/image aide lorsqu’on fournit les dimensions. Pour les iframes et widgets, fixez une hauteur minimale ou un ratio. Pour les polices via next/font, choisissez un fallback proche et acceptez un swap contrôlé plutôt qu’un FOIT interminable suivi d’un saut brutal.

Les inserts marketing dynamiques (bandeau promo, barre de notification, A/B hero) sont des usines à CLS s’ils apparaissent après le premier paint sans place réservée. Cadrez avec le marketing : soit le bandeau est dans le HTML initial, soit il s’affiche dans une zone déjà dimensionnée, soit il superpose sans pousser le flux. « On affichera le bandeau dès que l’API répond » sans réserve d’espace est une décision produit, pas une fatalité technique.

Enfin, attention aux animations de layout (height auto, insertion de DOM en tête de page). Animez transform et opacity quand c’est pertinent ; évitez de recalculer toute la page pour un effet décoratif. Un CLS « beau en staging » reste un CLS en production.

Une fois les mesures posées, construisez un backlog ordonné. Classez chaque correctif selon l’impact estimé sur la métrique prioritaire de la page, l’effort, et le risque métier. Remplacer le hero image d’une homepage à fort trafic bat presque toujours le micro-tuning d’une page légale. Retirer un script tiers non essentiel bat souvent une micro-optimisation de bundle sur une lib déjà tree-shake.

Travaillez par itérations courtes : une hypothèse, un changement, une remesure. Évitez le « gros PR performance » qui mélange images, refacto React et nouveau design system. Si le LCP s’améliore et l’INP régresse, vous devez pouvoir isoler la cause. Versionnez aussi les assets marketing : une campagne qui réintroduit un PNG 5 Mo annule trois sprints.

Impliquez le PO dans les arbitrages visibles. Dire « on coupe le carrousel autoplay du hero » est un arbitrage produit, pas un caprice dev. Dire « on décale le chat au second écran » aussi. La performance durable naît quand marketing, design et tech partagent un budget de poids et un budget de JS, écrits noir sur blanc dans le brief de refonte ou de campagne.

Sur Vercel, profitez des previews pour comparer avant/après sur la même URL de recette. Gardez une checklist de non-régression : LCP de la home, INP du menu mobile, CLS de la page avec consentement. Automatisez ce que vous pouvez (Lighthouse CI sur les URL critiques), mais ne remplacez pas le jugement terrain par un seuil unique magique.

Pour le LCP : identifiez l’élément LCP dans Performance panel, optimisez cet asset en premier, marquez-le en priority si c’est une image, vérifiez qu’il n’est pas lazy. Passez les polices critiques par next/font. Servez le contenu principal en Server Components. Supprimez les dépendances client au-dessus de la ligne de flottaison qui n’apportent pas d’interaction immédiate.

Pour l’INP : découpez les îlots clients, différéz les tags non essentiels, réduisez le travail synchrone sur les handlers (découpez les tâches longues, évitez le JSON.parse massif sur clic). Auditez le bundle avec l’analyzeur si besoin, mais commencez par supprimer ce qui ne devrait pas être là : double tracking, lib date entière pour formater une string, icônes importées en masse.

Pour le CLS : dimensions partout, skeletons pour les zones async, bandeaux réservés, embeds contenus. Testez le premier chargement avec cache froid et police non en cache. Vérifiez aussi le CLS post-consentement : beaucoup de sites « verts » avant bannière deviennent instables après acceptation des cookies.

Gardez une dette assumée. Tout ne sera pas parfait. Un commentaire de type plafond connu (budget JS, exception campagne) vaut mieux qu’une dette invisible. La lucidité Cosmos, c’est préférer un correctif simple et mesuré à une architecture performance sur-ingénierée que personne ne maintient.

La mise en production n’est pas la fin du pipeline. Surveillez les URL critiques pendant plusieurs semaines : saisonnalité, campagnes, nouveaux embeds, montée de version Next.js. Search Console signale les tendances de terrain ; Speed Insights aide à voir l’évolution par route. Définissez un propriétaire : qui regarde le rapport, à quelle cadence, quel seuil déclenche un ticket.

Installez une hygiène de merge. Toute PR qui touche layout racine, polices, consentement, hero ou tag manager doit mentionner l’impact perf attendu. Une revue design qui ajoute trois webfonts mérite la même attention qu’une revue qui ajoute une route API. Sinon, la « page d’accueil rapide » redevient lente en trois mois sans drame visible au moment du merge.

Préparez un playbook de régression : si le LCP home dépasse le seuil convenu en terrain, on gèle les ajouts marketing non critiques, on vérifie l’asset hero de la campagne en cours, on regarde les nouveaux scripts. Ce playbook évite le débat émotionnel du lundi matin.

Enfin, reliez performance et écoconception sans moralisme. Moins de poids, moins de JS, moins de sauts de layout : c’est souvent meilleur pour l’utilisateur, pour le budget d’infra, et pour la sobriété numérique. Ce n’est pas un badge ; c’est une conséquence d’un backlog bien tenu.

Les Core Web Vitals sur Next.js cassent surtout sur des choix concrets : images hero, polices, « use client » excessif, scripts tiers, absence de réserve d’espace. Le framework offre des leviers ; il ne corrige pas un brief sans budget de poids.

Mesurez lab et terrain, choisissez une métrique prioritaire par page critique, itérez avec remesure. Priorisez l’impact métier plutôt que le score cosmétique. Surveillez après livraison pour empêcher les campagnes et tags de reconstruire la dette.

LCP : image et typo d’abord, contenu serveur au-dessus de la ligne de flottaison. INP : réduire hydratation et tiers. CLS : dimensions et inserts stables. Aucune de ces actions ne garantit une position SEO ; toutes améliorent l’expérience réelle que vous pouvez défendre devant un client.

Gardez la méthode mesurée → prioriser → corriger → surveiller. C’est le seul pipeline qui tient en agence quand marketing, design et tech livrent en parallèle.