Performance
9 min 12 mars 2025
Core Web Vitals 2025 : ce qui change vraiment pour votre SEO
INP a remplacé FID. Voici ce que ça change concrètement pour vos classements Google, et la liste exacte des optimisations qui ont le plus d’impact en 2025.
Depuis mars 2024, Google a officiellement remplacé le FID (First Input Delay) par l’INP (Interaction to Next Paint) dans ses Core Web Vitals. Un an et demi plus tard, l’effet est mesurable : les sites qui n’ont pas adapté leur stack JavaScript voient leurs positions s’éroder, en particulier sur les pages produits, les blogs longs et les SaaS. Cet article détaille ce qu’il faut faire et dans quel ordre.
Les trois métriques officielles en 2025
LCP (Largest Contentful Paint) — moins de 2,5 s. Mesure la vitesse d’apparition du plus gros élément visible.
INP (Interaction to Next Paint) — moins de 200 ms. Mesure la réactivité globale aux interactions utilisateur.
CLS (Cumulative Layout Shift) — moins de 0,1. Mesure la stabilité visuelle pendant le chargement.
Pour figurer dans les bons résultats, il faut passer ces trois seuils sur le 75e percentile de vos pages. Une seule métrique en zone rouge suffit à pénaliser une URL.
Pourquoi l'INP est plus exigeant que le FID
Le FID ne mesurait que la première interaction. L’INP, lui, prend en compte toutes les interactions de la session et garde la pire. Un site React mal optimisé peut afficher 50 ms de FID mais 600 ms d’INP, simplement parce qu’un re-render lourd se déclenche au scroll ou au clic d’un menu.
Le piège classique React/Next.js
Un useState mal placé dans un composant haut dans l’arbre déclenche un re-render de toute la page à chaque interaction. C’est invisible à l’œil, mais l’INP explose.
Les 8 optimisations qui paient vraiment
Réduire le JavaScript bloquant : code-splitting par route et lazy loading des composants non critiques.
Optimiser les images : format AVIF/WebP, srcset responsive, attribut loading= »lazy » partout sauf au-dessus de la ligne de flottaison.
Précharger les polices critiques avec <link rel= »preload »> et utiliser font-display: swap.
Fragmenter les longues tâches JS en chunks de moins de 50 ms (technique « yield to main »).
Mémoriser correctement avec useMemo et useCallback dans les listes longues — pas partout, seulement où le profiler le justifie.
Réserver l’espace des images et iframes avec width/height pour éviter le CLS.
Déléguer l’analytics et les tags marketing à un Web Worker (Partytown) pour ne pas polluer le thread principal.
Utiliser les Server Components ou un rendu statique chaque fois que possible : moins d’hydration, moins d’INP.
Comment mesurer correctement
PageSpeed Insights est utile mais incomplet. Il donne deux choses : les données labo (Lighthouse, simulation) et les données terrain (CrUX, basées sur Chrome). Seules les données terrain comptent pour le SEO. Si vous n’avez pas assez de trafic pour apparaître dans CrUX, installez le Web Vitals JS library et envoyez les mesures à votre analytics.
Outils recommandés
Chrome DevTools — onglet Performance et Performance Insights.
Lighthouse CI dans votre pipeline pour empêcher les régressions.
Web Vitals Extension pour voir les mesures en direct sur n’importe quelle page.
Google Search Console — rapport « Signaux web essentiels » pour suivre les URLs problématiques.
Ce qu'on observe sur le terrain
Sur les 30 derniers audits que nous avons menés, 6 à 8 optimisations critiques ont été identifiables en moins d’une journée. Les gains de positionnement Google se voient en général 4 à 8 semaines après mise en production, plus vite sur les requêtes longue traîne. Les gains de conversion sont quasi immédiats : +1 % à +4 % de taux de conversion par 100 ms d’INP gagnés.
À retenir
Max Niedurny
M-Visual