Article · Performance · Web · 8 min de lecture
Core Web Vitals 2026 LCP, INP, CLS — les nouveaux signaux Google.
Depuis mars 2024, INP a remplacé FID dans les Core Web Vitals. En 2026, Google utilise plus que jamais ces trois métriques (LCP, INP, CLS) pour classer les sites mobiles. On vous explique comment les comprendre, les mesurer en NC, et les corriger.
Les 3 métriques qui comptent.
- LCP — Largest Contentful Paint : le temps que met le plus gros élément visible (image hero, titre, vidéo) à apparaître. Cible Google : moins de 2,5 s. Au-delà de 4 s, votre site est qualifié de « pauvre ».
- INP — Interaction to Next Paint : le temps entre une interaction utilisateur (clic, tap, frappe) et la mise à jour visuelle suivante. Cible : moins de 200 ms. Cette métrique a remplacé le FID en mars 2024 et mesure la réactivité réelle, pas seulement le premier clic.
- CLS — Cumulative Layout Shift : la stabilité visuelle de la page (les éléments qui sautent quand le contenu charge). Cible : moins de 0,1.
Ces trois métriques sont mesurées sur les visites réelles de vos utilisateurs (pas en laboratoire) via le rapport Chrome User Experience (CrUX). Google les agrège sur 28 jours glissants pour décider si votre site est rapide ou lent.
Pourquoi c’est plus dur en Nouvelle-Calédonie.
Trois facteurs creusent les Core Web Vitals d’un site NC face à un équivalent métropolitain :
- Latence transpacifique : si vos assets sont hébergés en Europe, chaque requête fait un aller-retour de 280-350 ms. Multiplié par 30-50 ressources sur une page lourde, c’est 8-15 s de délai cumulé.
- 4G hétérogène : très bonne en agglomération de Nouméa, médiocre en brousse, parfois saturée à des heures de pointe. Vos utilisateurs ne sont pas sur fibre métropolitaine.
- Devices vieillissants : un parc de smartphones moyens / d’occasion plus large, donc un INP qui souffre sur les sites JavaScript-lourds.
Conséquence : optimiser les CWV en NC n’est pas du luxe, c’est la condition pour que vos utilisateurs ne quittent pas la page.
Comment on optimise nos sites WordPress NC.
- LCP : hébergement local NC pour le HTML (Stratos), preload des fonts critiques, preload de l’image hero avec
fetchpriority="high", conversion JPEG → WebP automatisée. - INP : éviter les bibliothèques JavaScript lourdes (jQuery, frameworks SPA) sur les sites vitrine. Préférer du JS natif modulaire, défer tout ce qui n’est pas critique. Sur nos sites Wafer, le JS est en module ESM, ~30 KB total.
- CLS : toujours déclarer width et height sur les images, réserver l’espace des bandeaux dynamiques, éviter les polices custom sans fallback (utiliser
font-display: swap). - Cache navigateur agressif : Cache-Control immutable sur les assets versionnés, max-age 1 an. Gain massif sur les visites répétées.
- Compression Brotli activée côté serveur (LiteSpeed natif sur Hostinger).
Outils fiables en 2026.
- PageSpeed Insights (pagespeed.web.dev) : pour un audit ponctuel d’une URL, rapport CrUX réel + audit Lighthouse synthétique.
- Search Console > Expérience > Core Web Vitals : pour suivre les pages qui dérivent dans le temps.
- Web Vitals Chrome extension : mesure live pendant qu’on navigue, utile pour debug INP en particulier.
- web-vitals JS library : pour reporter les métriques réelles dans votre propre analytics, sans dépendance Google.
Sur la dernière refonte siteinternet.nc, on est passé de LCP 3 416 ms à 1 544 ms (-55 %) simplement en sortant les @import CSS bloquants vers du
preload as=style onload. Le gain perf est souvent caché dans 2-3 lignes de code.