Score SEO performance : Core Web Vitals, INP et les métriques qui font vraiment bouger les positions

La performance est le sous-score que la plupart des petits sites ratent pour la mauvaise raison : ils s'obsèdent sur des micro-optimisations de pages déjà rapides, ou ils ignorent des problèmes catastrophiques qui font plonger les positions. Ce guide se concentre sur les cinq métriques que Google mesure vraiment et l'ordre de correction qui vous fait passer au-dessus du seuil Core Web Vitals sans effort gaspillé. Le sous-score performance pèse 15% du score SEO + GEO recherche IA, et le franchir est binaire : soit vous passez les seuils, soit non.

Les cinq métriques qui comptent

LCP, INP et CLS sont les trois Core Web Vitals que Google utilise comme signal de classement. Le TTFB est une métrique de fondation qui affecte les trois. La taille de bundle est un signal UX corrélé à tout le reste.

Métrique 1 : LCP (Largest Contentful Paint)

Le LCP mesure combien de temps met le plus gros élément visible à s'afficher. C'est en général une image hero, un bloc de titre ou un grand paragraphe.

Tueurs de LCP fréquents sur les petits sites :

• Image hero lourde non optimisée
• Polices web custom qui bloquent le rendu initial
• Librairies JavaScript qui retardent l'affichage
• TTFB serveur lent qui se répercute sur le LCP

Ordre de correction :

1. Compressez et convertissez les images hero en WebP ou AVIF. Un PNG de 3MB devient un WebP de 200KB sans perte visible.
2. Définissez width et height explicites sur chaque image pour éviter les redistributions.
3. Utilisez fetchpriority="high" sur l'image principale au-dessus de la ligne de flottaison pour que le navigateur la priorise.
4. Préchargez les polices custom ou passez à font-display: swap pour que le texte soit visible immédiatement.
5. Lazy-loadez tout ce qui est sous la ligne de flottaison avec loading="lazy".

Métrique 2 : INP (Interaction to Next Paint)

L'INP a remplacé le FID en mars 2024 et il est nettement plus dur à passer. Alors que le FID ne mesurait que le délai de la première interaction (clic, tap, frappe), l'INP mesure la réactivité de chaque interaction de la page et remonte les pires outliers.

Ce qui casse l'INP :

• Event handlers JavaScript lourds (analytics, tracking, widgets de chat)
• Tâches longues sur le thread principal (gros re-renders React ou Vue)
• Scripts tiers qui monopolisent le thread principal
• Images non optimisées dans des flux en scroll infini

Ordre de correction :

1. Auditez les scripts tiers et retirez tout ce qui n'est pas business-critique. Chat live, analytics, tag managers.
2. Défere les scripts non critiques avec defer ou async.
3. Découpez les tâches longues avec requestIdleCallback ou scheduler.yield().
4. Debounce les handlers coûteux (input, scroll, resize).
5. Utilisez un CDN pour le code framework pour que les utilisateurs touchent une version cachée.

L'INP est la métrique qui échoue le plus souvent sur les sites à JavaScript lourd. Si votre score est rouge, la réponse est presque toujours "moins de JavaScript, pas plus d'optimisation".

Métrique 3 : CLS (Cumulative Layout Shift)

Le CLS mesure la stabilité visuelle. C'est la métrique qui énerve le plus les utilisateurs : les boutons qui sautent au moment où on clique.

Tueurs de CLS fréquents :

• Images sans width et height explicites
• Emplacements publicitaires qui s'étendent après le chargement
• Polices web qui basculent avec des tailles différentes
• Contenu injecté (bannières, modales) qui pousse la mise en page vers le bas

La correction : réservez l'espace pour tout ce qui se charge en asynchrone. Les images ont besoin de dimensions explicites, les slots pub d'un conteneur fixe, les iframes embarqués d'attributs width et height.

Métrique 4 : TTFB (Time to First Byte)

Le TTFB est le temps que met le serveur à commencer à répondre. Moins de 800ms c'est bon, plus de 1,8s c'est un problème de fondation qui plafonne toutes les autres métriques.

Le TTFB est surtout une décision d'hébergement :

Si votre TTFB dépasse 1,5s, aucune optimisation frontend ne vous sauvera. Corrigez d'abord l'hébergement, puis occupez-vous du LCP et de l'INP.

Métrique 5 : La taille de bundle

La taille de bundle est le poids total JavaScript, CSS et images sur mobile. Moins de 1,5MB est sain, plus de 3MB est un drapeau rouge, plus de 5MB est une catastrophe.

Audit rapide :

• Ouvrez Chrome DevTools > onglet Network
• Rechargez la page en émulation mobile avec cache désactivé
• Additionnez la taille transférée de toutes les ressources JS, CSS et images
• Retirez ou différez tout ce qui n'est pas nécessaire au contenu au-dessus de la ligne de flottaison

L'ordre de correction pour un score performance raté

Si votre sous-score performance est sous 50, déroulez cette séquence :

1. Corrigez le TTFB (upgradez l'hébergement ou ajoutez du cache) s'il dépasse 1,5s
2. Convertissez les images hero en WebP et fixez les dimensions
3. Retirez les scripts tiers inutiles (chat, heatmaps, trackers obsolètes)
4. Différez le JavaScript non critique avec defer ou async
5. Auditez le CLS sur vos 5 meilleures pages et réservez l'espace pour le contenu asynchrone

Mouvement de score attendu : 50 à 75 en deux semaines si vous suivez l'ordre. Les derniers 75 à 90 points demandent un travail plus fin (code splitting, critical CSS inline, remplacement de scripts tiers) et se mariant bien avec un audit SEO technique puisque beaucoup de problèmes se recoupent.

La performance est le sous-score où l'effort et le résultat sont les plus prévisibles. Vous mesurez, vous corrigez, vous remesurez. Pas de mystère : les seuils sont publics, les métriques sont standardisées, et l'ordre de correction est le même pour la plupart des sites. Passez la barre Core Web Vitals, puis arrêtez-vous et dépensez votre énergie sur le contenu et l'E-E-A-T où l'effet cumulatif est plus fort.