Vérificateur de Core Web Vitals (INP, LCP, CLS)

Ce que veulent dire les Core Web Vitals en 2026 et pourquoi l'INP a remplacé le FID

Les Core Web Vitals sont des chiffres issus des données terrain sur lesquels Google s'appuie pour son signal d'expérience de page, celui qui alimente le classement mobile-first. En 2026, il y en a trois qui comptent. Le LCP, Largest Contentful Paint, mesure la vitesse à laquelle ton plus gros élément visible s'affiche vraiment. L'INP, Interaction to Next Paint, mesure le temps que la page fait attendre quelqu'un après un tap ou un clic. Le CLS, Cumulative Layout Shift, indique si les éléments sautent dans tous les sens pendant le chargement. L'INP a pris la place du First Input Delay le 12 mars 2024, et honnêtement ça n'était pas trop tôt. Le FID ne chronométrait jamais que la première interaction. L'INP, lui, surveille la pire sur toute la visite, ce qui colle bien plus à la sensation d'une appli sous tes doigts.

Sous le capot, j'appelle l'API PageSpeed Insights de Google et je lis deux couches complètement différentes pour l'URL que tu me donnes. Première couche : CrUX, le Chrome User Experience Report. C'est de la donnée anonyme issue de vrais utilisateurs de Chrome, agrégée sur les 28 derniers jours glissants et reportée au 75e centile. C'est la donnée sur laquelle Google classe réellement, donc c'est celle qui m'intéresse le plus, et de loin. Deuxième couche : un passage Lighthouse en labo sur le matériel de Google. Il ajoute des extras comme le FCP, le TBT et le Speed Index, plus un score de 0 à 100. Chaque métrique est peinte en vert, ambre ou rouge selon les seuils de Google. Là où ça coince, je t'explique pourquoi en clair, sans te noyer sous le jargon.

Comment fonctionne la sonde

1. Normalise l'URL. Tu as oublié le https:// ? Je te le rajoute.
2. Lance deux requêtes PageSpeed Insights en parallèle, une en strategy=mobile et une en strategy=desktop. PSI renvoie le même payload CrUX et Lighthouse pour chacune, donc la comparaison côte à côte ne te coûte rien de plus.
3. Extrait les métriques terrain depuis loadingExperience.metrics. À savoir LCP, INP, CLS, FCP et le TTFB expérimental, et chacun arrive avec sa valeur au 75e centile plus la répartition vert / à améliorer / mauvais.
4. Extrait les métriques de labo depuis lighthouseResult.audits.metrics.details.items[0] : le TBT (Total Blocking Time, que le labo utilise comme substitut à l'INP), le Speed Index, le Server Response Time et le score global.
5. Note par rapport aux seuils Google et trace une petite barre montrant où chaque valeur tombe dans les zones vert/ambre/rouge. Les seuils, au cas où tu les aurais oubliés : l'INP est bon en dessous de 200 ms, fragile entre 200 et 500 ms, mauvais au-delà de 500 ms. Le LCP bon sous 2.5 s, fragile jusqu'à 4 s, mauvais après. Le CLS bon sous 0.1, fragile jusqu'à 0.25, mauvais au-dessus.

Cas d'usage courants pour une sonde Core Web Vitals

• Validation SEO avant une mise en ligne. Sors une refonte avec un CLS rouge ou un INP mobile mauvais et tu offres discrètement tes positions à un concurrent. Du coup je lance ça sur chaque page publique avant qu'un nouveau design ne parte en prod. À chaque fois, sans jamais sauter l'étape.
• Vérification de migration. Tu as changé de CMS, de serveur ou de CDN ? Fais une capture des chiffres CrUX d'abord, puis garde-les à l'oeil pendant les semaines qui suivent. Ce sont des données glissantes sur 28 jours, donc la nouvelle référence ne sortira pas du jour au lendemain. Patience.
• Due diligence fournisseur. Avant de signer avec un SaaS qui va héberger tes pages clients, pointe ça sur leurs démos publiques. Si leur propre INP est rouge sur toute la ligne, eh bien, c'est l'entonnoir de conversion dont tu vas hériter.
• Justifier un refactoring front-end. Tu essaies d'obtenir du temps pour démêler une SPA boursouflée ? Mets le chiffre d'INP terrain sur la slide. Je n'ai jamais rien trouvé qui débloque une discussion budgétaire plus vite.
• Démontage concurrentiel. Aligne ta page d'accueil face à tes principaux rivaux sur mobile. Le contenu peut être totalement équivalent, la page la plus rapide rafle quand même les clics.
• Audit mobile-first. Pour la plupart des sites B2C, c'est sur mobile que le trafic vit vraiment aujourd'hui. Desktop vert mais mobile rouge ? Tu perds de l'argent, et pas dans un futur hypothétique, aujourd'hui.

Limites et précisions sur la précision

Parlons franchement de ce que ça peut te dire et de ce que ça ne peut pas. L'onglet terrain tourne sur CrUX, et CrUX ne porte des chiffres que pour les URL qui ont assez de vrai trafic Chrome derrière elles. Les pages à faible trafic ou fraîchement lancées reviennent avec « No field data available » et tu ne verras que les chiffres du labo Lighthouse. CrUX, c'est aussi cette fenêtre glissante de 28 jours, donc un correctif que tu as déployé hier ne l'aura pas encore bougée. Côté labo, c'est un seul passage Lighthouse sur le matériel de Google. Je l'ai vu varier de 5 à 15 % entre deux passages consécutifs sur la même URL, alors prends-le comme une tendance et pas comme un verdict. Et le tout repose sur l'API publique PageSpeed Insights v5, plafonnée autour de 4 requêtes par seconde et par IP sans clé. Tu tapes ce mur ? Colle ta propre clé dans le champ ci-dessus.

Une chose qui mérite d'être dite clairement : l'URL que tu testes part chez Google dans le cadre de la requête, exactement comme sur la page PageSpeed Insights de Google. Mon serveur ne touche jamais à l'appel. Rien de ce que tu tapes ne reste sur PeopleAreGeek une fois la sonde terminée.

Questions fréquentes

Pourquoi l'INP compte plus que le FID ?

Le FID ne chronométrait jamais que ta toute première interaction sur la page. Un tap, terminé. L'INP, lui, continue de surveiller et attrape l'interaction la plus lente sur toute la visite, ce qui colle bien mieux à la sensation réelle d'utilisation. Personne ne se souvient vraiment du premier clic. Celui qui a ramé pendant une demi-seconde, par contre, celui-là reste en mémoire.

C'est quoi une bonne valeur d'INP ?

Sous les 200 millisecondes, c'est la zone verte. Entre 200 et 500, c'est à améliorer, et tout ce qui dépasse 500 est mauvais. Voici le piège que la plupart des gens ratent. Google le mesure au 75e centile des vrais utilisateurs de Chrome sur les 28 derniers jours glissants. Que ta médiane soit réactive ne suffit pas en soi. C'est le quart le plus lent de tes visiteurs qui doit être en bon état, et c'est cette partie-là qui mord, en général.

Pourquoi l'onglet desktop est vert alors que le mobile est rouge ?

Des CPU plus faibles, des réseaux plus capricieux. C'est en gros toute l'histoire. Un bundle JavaScript qui se parse en 200 ms sur ta machine de dev peut en avaler 1500 sur le milieu de gamme Android que les gens trimballent vraiment. Et le pire, c'est que c'est le score mobile que Google utilise pour classer en mobile-first indexing. Corrige le mobile en premier. Un desktop vert, c'est sympa à avoir, bien sûr, mais ce n'est pas ce qui t'amène du trafic.

C'est quoi le TBT et pourquoi le labo s'en sert ?

Le Total Blocking Time additionne chaque tranche où le thread principal est resté bloqué par des tâches longues, tout ce qui dépasse 50 ms, entre le FCP et le TTI en labo. Le labo ne peut rien cliquer pour de vrai, donc il ne peut pas mesurer l'INP directement. Le TBT est le meilleur substitut qu'il a. Ma règle approximative, et j'exagère peut-être la corrélation, c'est qu'un TBT élevé en labo annonce souvent un INP mauvais sur le terrain. Souvent. Pas une loi.

Ai-je besoin d'une clé API Google ?

Pour un coup de sonde de temps en temps ? Non. Le quota anonyme te porte sans problème. Une clé ne devient rentable que quand tu enchaînes des audits en boucle dans un script et que tu butes sur la limite de débit. C'est gratuit dans les deux cas. Tu en récupères une sur console.cloud.google.com et tu actives l'API PageSpeed Insights.

Combien de temps faut-il pour qu'une amélioration apparaisse dans CrUX ?

Plus lentement que tu ne voudrais. CrUX fait rouler une fenêtre de 28 jours, donc un correctif que tu déploies aujourd'hui ne fait bouger le chiffre terrain que petit à petit, à mesure que les anciens jours sortent de l'échantillon. Je ne ferais pas confiance à un avant/après propre avant environ 35 à 45 jours après le déploiement. Au troisième jour, j'ai un jour crié victoire à tort. Leçon retenue.