Mesurer la performance d'un site (Core Web Vitals 2026, INP)

Bon, faut que je vous raconte un truc. En septembre 2024, Jean (gérant d'une PME de chassis à Genappe) débarque chez moi en disant "mon site rame, Google m'a envoyé un mail bizarre, j'comprends rien". Je regarde la Search Console : LCP à 6,4 secondes sur mobile, INP à 720 ms. Catastrophique. Du coup on a passé un après-midi dessus et franchement, j'ai tout réglé avec genre 4 modifs. Pas 40. Quatre. Le reste c'était du bruit.

Je bosse sur de la perf web, donc j'en ai vu passer des sites lents. Et honnêtement, l'industrie autour des Core Web Vitals s'est transformée en cirque marketing. Les agences vendent des "audits perf" à 1500 € qui te sortent 80 recommandations dont 75 te font gagner 12 ms. Bref, dans ce guide je vous dis ce qui paye vraiment vs ce qui est du micro-tuning.

Les 3 trucs que Google regarde en 2026

Petit rappel parce que ça bouge tout le temps. Depuis mars 2024, l'INP a remplacé le FID (qui était nul de toute façon, il mesurait que la première interaction). Maintenant on a :

• LCP (Largest Contentful Paint) : combien de temps avant que le gros élément visible apparaisse. Cible : sous 2,5 s.
• INP (Interaction to Next Paint) : quand l'utilisateur clique ou tape, combien de temps avant que ça réagisse visuellement. Cible : sous 200 ms.
• CLS (Cumulative Layout Shift) : à quel point la page saute pendant qu'elle charge. Cible : sous 0,1.

Et un détail que tout le monde oublie : Google ne regarde pas un test fait sur ses serveurs. Il regarde les vraies données de vos vrais utilisateurs Chrome (le truc s'appelle CrUX). C'est le 75e percentile sur 28 jours glissants. J'me suis fait avoir au début, je testais en local sur ma fibre 1 Gb/s , évidemment tout était vert. Mes clients sur 4G en Hesbaye, eux, en bavaient.

Avec quoi on mesure (vraiment)

Y a 3000 outils. J'en utilise quatre, basta.

Search Console, panneau "Expérience". C'est le SEUL qui compte vraiment, parce que c'est ce que Google voit. Si c'est vert là-dedans, vous avez gagné. Le reste c'est de la diagnostic.

PageSpeed Insights pour creuser : vous tapez l'URL, ça vous donne les chiffres CrUX en haut (vrais utilisateurs) et un audit Lighthouse en bas (synthétique, à prendre avec des pincettes). Regardez le haut. Le bas c'est indicatif.

Chrome DevTools onglet Performance quand vous voulez débugger localement. Faut un peu apprendre mais c'est imbattable pour comprendre où le JS bloque.

WebPageTest quand un client râle "ça rame depuis Bruxelles" : on lance un test depuis un node EU sur connexion 4G, et là on voit la vérité.

Tout le reste (Sentry RUM, Cloudflare Analytics, machin SaaS à 90$/mois) c'est nice-to-have. Pour une TPE belge, Search Console + PageSpeed gratuits font 95 % du job.

LCP : 4 trucs qui rapportent gros

Le LCP c'est presque toujours une image (ou parfois un titre H1 sur les pages bavardes). Et 9 fois sur 10, le problème c'est que cette image fait 1,8 Mo en JPEG des années 2010.

Ce que je fais quand un client me passe son site lent :

1. La compression de l'image LCP. Je passe en WebP, je vise sous 100 Ko pour du 1200x675. Sur le site de Jean ça a fait passer le LCP de 6,4 à 3,1 secondes. Trois secondes gagnées avec un cwebp en ligne de commande. C'est ridicule mais ça marche.

2. fetchpriority="high" sur la balise img du LCP. 2 attributs HTML, gain typique 300 à 800 ms. Un truc que je rajoute systématiquement maintenant. Y en a qui le savent toujours pas en 2026.

3. Le preload de la police critique. Si votre H1 utilise une Google Font et qu'elle charge en retard, le LCP attend. Un <link rel="preload"> bien placé règle ça.

4. Le TTFB de l'hébergement. Là je vais être direct : si vous êtes chez OVH mutualisé à 4€/mois et que votre TTFB est à 900 ms, vous pouvez optimiser ce que vous voulez, vous y arriverez pas. Hébergement décent (genre Combell, Hetzner, ou un VPS managé) , TTFB sous 200 ms , et la vie devient possible.

Le reste (lazy-loading des images sous la ligne de flottaison, dimensions explicites, etc.) je le fais aussi, mais en termes d'impact c'est ces 4 là qui changent tout.

INP : la galère du JS

L'INP c'est le nouveau cauchemar de tous les sites WordPress. Pourquoi ? Parce que un site WP moyen charge 14 plugins, chaque plugin charge son JS, et le navigateur passe sa vie à parser tout ça pendant que l'utilisateur clique dans le vide.

Y a pas de baguette magique, désolé. Mais les 3 trucs qui m'ont sauvé sur des cas réels :

Audit des plugins. Sérieusement. Sur un site client de Wavre en mai 2025 j'ai viré 6 plugins sur 18 (sliders qu'on utilisait plus, contact form 7 doublonné par WPForms, trois trucs SEO redondants), INP passé de 480 ms à 180 ms. Sans toucher à une ligne de code.

Le defer sur le JS non critique. Tracking, analytics, chat widget, tout ça. Ça vide le thread principal au moment où l'utilisateur veut interagir.

Le découpage des longues tâches. Si vous avez du JS custom qui boucle sur 2000 items au chargement, faut le découper en chunks avec des setTimeout(0) ou des requestIdleCallback. Ça parait con mais ça suffit souvent.

Pour les sites sur-mesure que je code, j'évite tout simplement le JS lourd. HTMX + un peu de vanilla JS et on est tranquille. Mais bon, j'comprends que tout le monde n'a pas ce luxe.

CLS : facile à régler, souvent oublié

Le CLS c'est presque toujours :

Des images sans width et height. Le navigateur sait pas combien de place réserver, donc le contenu saute quand l'image charge. Solution : balance les attributs , même approximatifs c'est mieux que rien.

Les Google Fonts qui changent la mise en page quand elles arrivent. Le truc c'est font-display: swap + une fallback qui matche en taille. Y a un outil sympa, fontsource.org, qui aide à trouver des polices similaires.

Le bandeau cookies qui pousse tout vers le bas. Mettez-le en overlay flottant, ou en bas. Pas en haut qui décale tout.

Honnêtement, le CLS c'est le plus facile des trois. Une après-midi de boulot et c'est plié.

Le piège du score 100/100

Je vais être un peu provoc. Avoir 100/100 sur PageSpeed sert à rien. Strictement rien. Ce que vous voulez c'est tous les CWV en vert sur Search Console, point. C'est pas pareil.

J'ai un client à Ottignies qui faisait du 95/100 sur PSI mais qui était en orange sur Search Console pour l'INP. Pourquoi ? PSI utilisait sa propre simulation, alors que les vrais utilisateurs (souvent sur de vieux Android pourris) galéraient. On a optimisé pour les conditions réelles , PSI est tombé à 78/100 mais Search Console est passé tout vert. Conversions en hausse de 14 % le trimestre suivant.

Et le SEO dans tout ça ?

Soyons clairs. Google a annoncé en 2021 que les CWV seraient un facteur de ranking. En vrai c'est un tie-breaker entre pages de qualité comparable. Le contenu reste le truc principal. J'ai des clients qui sont en orange CWV et qui rankent parce que leur contenu est très bon. J'en ai d'autres en vert qui rankent pas parce que leur contenu est nul.

Mais. Un site lent perd des visiteurs. 53 % des mobiles partent au-delà de 3 secondes. C'est l'impact business qui doit vous motiver, pas l'impact SEO direct. Les CWV c'est de l'UX déguisée , et l'UX ça vend.

La checklist que je donne à mes clients

Tiens, ce que je leur file en fin de mission :

• Search Console = le seul tableau de bord à regarder. Tout y est vert ou rien.
• Image LCP en WebP, sous 100 Ko, avec fetchpriority="high"
• Toutes les autres images avec loading="lazy" et width/height
• Polices avec font-display: swap + preload de la critique
• JS non critique en defer, tracking en bas de page
• Hébergement avec TTFB sous 200 ms (sinon, vous changez d'hébergeur)
• Bandeau cookies en overlay, pas en haut
• Test mensuel sur PSI des 5 pages les plus visitées

Voilà. Si vous êtes une TPE belge avec un site WordPress qui rame ou un site sur-mesure qui galère sur l'INP, écrivez-moi. En général une demi-journée suffit pour identifier les 3 ou 4 trucs qui plombent tout. Le reste c'est du tuning marketing pour vendre des heures.