Les trois métriques Core Web Vitals et leurs seuils 2026
Google mesure l'expérience utilisateur à travers trois métriques principales, regroupées sous le terme Core Web Vitals. Chacune dispose d'un seuil « Good » et d'un seuil « Needs Improvement » au-delà duquel le rang est affecté.
LCP — Largest Contentful Paint. Mesure le temps d'affichage du plus grand élément visible (image hero, bloc texte principal). Seuil Good : ≤ 2 500 ms. Seuil Needs Improvement : entre 2 500 ms et 4 000 ms. Au-delà de 4 000 ms, la page est classée Poor.
INP — Interaction to Next Paint. Introduit en remplacement de FID, INP mesure la latence entre un geste utilisateur (clic, frappe, appui tactile) et le prochain rendu visuel. Seuil Good : ≤ 200 ms. Seuil Needs Improvement : entre 200 ms et 500 ms. Au-delà de 500 ms : Poor.
CLS — Cumulative Layout Shift. Mesure l'instabilité visuelle de la page — décalages de blocs pendant le chargement. Seuil Good : ≤ 0,1. Seuil Needs Improvement : entre 0,1 et 0,25. Au-delà de 0,25 : Poor.
Ces seuils s'appliquent aux données de terrain (CrUX), pas aux scores de laboratoire. Un score PageSpeed Insights de 90 en laboratoire ne garantit pas que les vrais utilisateurs passent le seuil — la distinction est importante pour les agences qui reportent des métriques à leurs clients.
- Rang de recherche dégradé — Google intègre les Core Web Vitals dans son signal Page Experience depuis 2021 ; un site classé Poor sur LCP ou INP perd des positions face à un concurrent comparable dont les métriques sont au vert.
- CTR en baisse sur mobile — les résultats bien positionnés bénéficient d'une étiquette implicite de confiance ; un chargement lent perçu par l'utilisateur après le clic augmente le taux de rebond et signale un signal négatif d'engagement.
- Taux de conversion réduit — chaque seconde supplémentaire de LCP au-delà de 2,5 s est corrélée à une hausse du taux d'abandon panier ; pour un site e-commerce, un TTFB de 1 200 ms peut effacer une part significative du chiffre d'affaires généré par le SEO.
- Coût publicitaire accru — un Quality Score Google Ads intègre l'expérience de la page de destination ; un LCP Poor dégrade le score et fait monter le CPC pour le même mot-clé.
- Perte de clients d'agence — lorsque le rapport mensuel d'un client montre un INP rouge, la question arrive immédiatement ; sans infrastructure à même de tenir les seuils, l'agence ne peut pas promettre de résolution durable.
- Indexation mobile ralentie — Googlebot mobile suit le même délai de rendu que les utilisateurs ; un TTFB élevé ralentit le crawl et peut retarder l'indexation de nouvelles pages.
- Expérience utilisateur mesurable — un INP supérieur à 500 ms rend les interactions (menus, filtres, formulaires) perceptiblement lentes ; les retours utilisateurs négatifs précèdent souvent les alertes de métriques.
Comment le TTFB bloque le LCP : la chaîne causale
Le TTFB (Time to First Byte) est le temps entre la requête HTTP du navigateur et réception du premier octet de réponse serveur. C'est le plancher incompressible de tout le reste.
Sur une connexion mobile standard (4G médian), le navigateur dispose d'environ 2 500 ms pour atteindre le seuil LCP Good. Sur ce budget, la résolution DNS, le handshake TLS et le TTFB sont prélevés en premier. Un TTFB de 800 ms — courant sur un mutualisé saturé — laisse 1 700 ms pour le téléchargement HTML, le parsing, le chargement des ressources bloquantes et le rendu de l'élément LCP. En pratique, ce budget est insuffisant.
La chaîne causale est la suivante : le serveur génère la page (PHP, base de données), puis envoie le premier octet. Si PHP-FPM n'est pas activé et que le serveur utilise mod_php en mode préfork, chaque requête monopolise un worker Apache entier. Sous charge, les workers s'épuisent et les requêtes entrent en file d'attente. Le TTFB s'allonge de façon non linéaire — un mutualisé saturé peut dépasser 1 200 ms de TTFB alors qu'à vide il affiche 200 ms.
Ajouter un cache objet Redis réduit ce temps de façon significative : au lieu d'exécuter 40 à 80 requêtes SQL pour composer une page WordPress, le cache retourne le résultat précompilé en quelques millisecondes. Sans Redis, chaque miss de cache de page intégrale (WP Rocket, W3TC) provoque une régénération complète qui repousse le TTFB bien au-delà de 600 ms.
HTTP/3 (QUIC) réduit la latence de connexion en éliminant le round-trip supplémentaire du handshake TCP+TLS, ce qui est particulièrement sensible sur mobile et sur les réseaux à perte de paquets. L'activation requiert un serveur qui supporte QUIC — ce n'est pas disponible sur tous les hébergements mutualisés.
Mutualisé saturé vs VPS avec PHP-FPM et Redis
| Critère | Mutualisé saturé | VPS + PHP-FPM + Redis |
|---|---|---|
| TTFB médian sous charge | 800 – 1 200 ms | 120 – 250 ms |
| Exécution PHP | mod_php préfork (worker partagé) | PHP-FPM (pool dédié, non-bloquant) |
| Cache objet | Non disponible ou désactivé | Redis socket local, latence < 1 ms |
| HTTP/3 (QUIC) | Rarement disponible | Configurable sur nginx / Caddy |
| Score LCP (terrain) | Needs Improvement à Poor fréquent | Good atteint sur connexion standard |
| Score INP (terrain) | Dépend du JS côté client | JS identique, mais moins de blocages réseau |
| Isolation des ressources | CPU et mémoire partagés entre clients | Ressources dédiées, pas d'effet voisin |
Optimiser le stack serveur côté hébergeur
Activer PHP-FPM à la place de mod_php
Sur Apache, remplacer mod_php par PHP-FPM avec mpm_event supprime le blocage des workers sur les requêtes lentes. Vérifier le mode actif : apache2ctl -M | grep php. Sur nginx, PHP-FPM est le seul mode disponible — s'assurer que le pool est dimensionné pour la charge (pm.max_children à calculer selon la RAM disponible divisée par la consommation moyenne d'un worker).
Configurer Redis comme cache objet WordPress
Installer Redis sur le serveur (apt install redis-server ou via le gestionnaire de paquets de la distribution). Activer le socket Unix plutôt que TCP pour réduire la latence : unixsocket /var/run/redis/redis.sock. Dans WordPress, installer un plugin de cache objet Redis (par exemple redis-cache) et pointer sur le socket. Vérifier l'activation avec wp redis status — le statut doit afficher Connected.
Activer la compression Brotli et Gzip
Brotli offre un taux de compression supérieur à Gzip sur les ressources texte (HTML, CSS, JS). Sur nginx, vérifier la disponibilité du module : nginx -V 2>&1 | grep brotli. En l'absence de Brotli, Gzip reste efficace : gzip_comp_level 6; gzip_types text/plain text/css application/javascript application/json image/svg+xml;. Activer la compression pré-compressée (.gz statiques) pour les ressources qui ne changent pas.
Activer HTTP/3 (QUIC) sur nginx ou Caddy
Caddy active HTTP/3 par défaut sans configuration supplémentaire. Sur nginx, la disponibilité dépend de la version compilée : nginx -V 2>&1 | grep http3. Ajouter dans le bloc server : listen 443 quic reuseport; add_header Alt-Svc 'h3=":443"; ma=86400';. Ouvrir le port UDP 443 dans le pare-feu (ufw allow 443/udp). Valider avec curl --http3 -I https://mondomaine.com.
Configurer les en-têtes de cache navigateur
Les ressources statiques (images, polices, CSS, JS versionnés) doivent porter Cache-Control: public, max-age=31536000, immutable. Les pages HTML doivent porter Cache-Control: no-store ou un max-age court si un cache de page est actif en amont. Vérifier les en-têtes en production : curl -I https://mondomaine.com/wp-content/themes/mon-theme/style.css.
Activer le cache de page serveur (si non géré par le CDN)
Un cache de page serveur (FastCGI cache nginx, ou module Varnish) retourne la page HTML précompilée sans toucher PHP ni la base de données. Le TTFB chute significativement pour les pages mises en cache. Exclure les pages de panier, de compte et les pages avec cookie de session de la mise en cache : fastcgi_cache_bypass $cookie_woocommerce_items_in_cart;.
Mesurer le TTFB en conditions réelles avec WebPageTest
Exécuter un test depuis webpagetest.org en sélectionnant un point de présence proche de la cible géographique des clients. Choisir un profil mobile (Moto G4 ou équivalent) et une connexion 4G simulée. Dans les résultats, lire la colonne TTFB de la cascade — elle isole le temps serveur du temps réseau. Comparer les runs à chaud (cache présent) et à froid (cache vidé via le paramètre de test).
Vérifier l'impact réel via CrUX et Search Console
PageSpeed Insights affiche les données CrUX pour le domaine analysé lorsqu'elles sont disponibles (volume de trafic suffisant). Les métriques de terrain apparaissent dans la section « Field data » — ce sont les seules qui comptent pour Google. Dans Search Console, le rapport « Expérience sur la page » agrège les URL par statut (Good / Needs Improvement / Poor) sur 28 jours glissants.
Mesurer correctement : WebPageTest vs PageSpeed Insights
WebPageTest et PageSpeed Insights mesurent des choses différentes, et les confondre conduit à de mauvaises décisions.
PageSpeed Insights exécute un audit Lighthouse en laboratoire — conditions contrôlées, appareil simulé, réseau simulé. Le score affiché (0 à 100) est une note d'opportunités d'amélioration, pas une mesure de la performance réelle des utilisateurs. Un site peut afficher 95 en laboratoire et être classé Poor en données de terrain si le contenu dynamique ou les interactions JavaScript dégradent les métriques réelles. Le score PageSpeed Insights n'est pas le rang Google.
WebPageTest permet de configurer précisément le point de test géographique, le profil d'appareil et la simulation réseau. Il expose la cascade de chargement complète, les timings DNS/TCP/TLS/TTFB, et permet les tests multi-étapes pour mesurer INP sur une interaction simulée. Pour diagnostiquer un TTFB élevé, WebPageTest est l'outil de référence.
Les données CrUX (Chrome User Experience Report) collectent les métriques réelles des utilisateurs Chrome sur 28 jours. Elles sont disponibles via PageSpeed Insights, Search Console et l'API CrUX directement. Ce sont ces données que Google utilise pour le classement — pas le score Lighthouse.
Lire le rapport CrUX dans Search Console : ouvrir la propriété, aller dans « Expérience sur la page », puis « Rapport sur les Core Web Vitals ». Le rapport distingue mobile et desktop. Cliquer sur « Good URLs » ou « Poor URLs » pour voir quelles pages sont concernées. Si le volume de données est insuffisant (site à faible trafic), les données CrUX ne s'affichent pas — utiliser alors PageSpeed Insights sur les URL clés et noter que l'impact sur le rang reste réel même sans rapport Search Console disponible. Pour les clients d'agence à trafic faible, se concentrer sur les mesures WebPageTest et les seuils absolus plutôt que sur les rapports CrUX.
Dépannage : quatre cas courants
TTFB correct mais INP rouge. Un TTFB inférieur à 250 ms ne garantit pas un INP sous 200 ms. INP mesure la réactivité aux interactions, pas le chargement initial. Les causes fréquentes d'un INP élevé malgré un bon TTFB : un thread principal JavaScript bloqué par des scripts tiers (analytics, chatbots, publicités) pendant la phase d'interactivité ; des tâches longues (Long Tasks > 50 ms) qui retardent le rendu suivant un clic ; un hydratation Vue ou React coûteuse sur une page SSR. Le diagnostic se fait dans Chrome DevTools > Performance, en enregistrant une interaction et en identifiant les tâches longues sur le thread principal.
INP passe en lab mais pas en field. Les outils de laboratoire (Lighthouse, WebPageTest) mesurent INP sur des interactions simulées dans des conditions contrôlées. En données de terrain, l'INP inclut toutes les interactions de tous les utilisateurs, y compris celles sur des appareils bas de gamme avec des scripts tiers chargés, des extensions de navigateur actives et une connexion variable. Un INP de 180 ms en laboratoire peut dépasser 500 ms en terrain si un script tiers bloque le thread principal pendant le premier chargement. Identifier les scripts tiers avec webpagetest.org et mesurer leur impact sur le thread principal.
LCP lent malgré Cloudflare. Cloudflare met en cache les ressources statiques, mais ne met pas en cache les pages HTML par défaut (sauf configuration explicite via Page Rules ou Cache Rules). Si le LCP est porté par un élément HTML (texte ou image incluse dans le HTML), le TTFB de la page HTML détermine toujours le LCP. Vérifier l'en-tête CF-Cache-Status dans la réponse HTTP : curl -I https://mondomaine.com | grep CF-Cache-Status. Si la valeur est DYNAMIC ou BYPASS, la page n'est pas en cache Cloudflare et le TTFB serveur s'applique intégralement.
CLS qui régresse après mise à jour de thème. Le CLS est sensible aux ressources qui chargent avec des dimensions non spécifiées (images sans width/height, polices web qui causent un FOIT/FOUT, bannières injectées par JavaScript). Après une mise à jour de thème, vérifier systématiquement que les images ont des attributs de dimensions explicites et que les polices web utilisent font-display: swap ou optional. Inspecter la session d'enregistrement CLS dans PageSpeed Insights (section « Diagnostics ») pour identifier l'élément qui décale.
Ce que l'agence peut promettre à ses clients
Un rapport PageSpeed rouge n'est pas une fatalité, mais il faut distinguer ce qui relève de l'hébergement de ce qui relève du code client.
Côté hébergement, les engagements mesurables sont : un TTFB inférieur à 250 ms avec un VPS correctement configuré, la disponibilité de PHP-FPM avec un pool dimensionné, un cache objet Redis actif, et la compression Brotli ou Gzip sur les ressources texte. Ces quatre points couvrent la part serveur du LCP et réduisent mécaniquement le risque de dépasser 2 500 ms sur une page optimisée côté client.
INP reste partiellement sous la responsabilité du code front-end — les scripts tiers, l'hydratation JavaScript et les tâches longues ne dépendent pas de l'hébergeur. Ce que l'hébergement peut faire pour INP : réduire le TTFB (moins de temps d'attente avant que le JS commence à s'exécuter), activer HTTP/3 (moins de latence sur les ressources bloquantes), et ne pas introduire de contention CPU qui rallongerait les tâches JavaScript côté serveur lors du rendu SSR.
Une agence qui gère un portefeuille de clients peut garantir les seuils côté serveur, documenter les mesures WebPageTest et CrUX par domaine, et isoler les régressions à leur source — thème, plugin, script tiers ou capacité serveur. C'est cette capacité d'isolation qui fait la différence entre une agence qui subit les rapports PageSpeed et une agence qui les pilote.
