Les données de terrain décrivent des visites passées ; celles de laboratoire, un test contrôlé. PageSpeed Insights les réunit alors qu’elles couvrent des appareils, comportements et périodes différents. Utilisez le terrain pour comprendre l’expérience réelle et les traces de laboratoire pour rechercher les causes et tester les changements.
Un Lighthouse vert ne prouve pas que les visiteurs satisfont aux Core Web Vitals. Un test synthétique lent ne réfute pas non plus de bons résultats réels. Identifiez d’abord ce que chaque nombre représente. L’introduction aux Core Web Vitals explique les métriques ; ce guide explique les écarts de mesure.
Commencer par la population et la question
CrUX, le Chrome User Experience Report, agrège les expériences d’utilisateurs Chrome éligibles. Ce n’est pas le recensement de tous vos visiteurs. La participation dépend d’options du navigateur, d’environnements compatibles et d’un nombre suffisant d’observations. Google ne publie pas de seuil universel de trafic garantissant l’inclusion.
La page doit aussi respecter les critères de découverte publique et d’indexabilité. Recevoir des visites n’impose pas qu’un espace privé figure dans CrUX. Il n’existe pas d’envoi manuel permettant de forcer cette présence. Sans données, cette source ne répond simplement pas à la question.
Une navigation Lighthouse charge une URL dans un navigateur configuré. Elle fournit un diagnostic sans attendre de visiteurs, y compris avant publication. Ce scénario ne représente toutefois pas la distribution réelle de votre audience.
Voici les questions auxquelles les deux sources peuvent répondre.
| Dimension | Terrain CrUX dans PSI | Navigation Lighthouse |
|---|---|---|
| Population | Visites réelles Chrome éligibles | Un chargement contrôlé |
| Période | Les 28 jours précédents | Le test actuel |
| Appareils | Matériel observé, par catégorie | Profil et limitations configurés |
| Comportement | Usage réel pendant les visites | Navigation et durée observée |
| Utilité | Problèmes persistants des visiteurs | Diagnostic et comparaison des changements |
| Limite | Agrégation et éligibilité | Un scénario ne couvre pas tous les parcours |
Ne pas confondre centile et moyenne
La valeur affichée est généralement le 75e centile, ou p75. Un LCP de 2,4 secondes au p75 signifie qu’au moins 75% des expériences observées ont atteint ce jalon en 2,4 secondes ou moins. Ce n’est ni l’attente de chaque visiteur ni la moyenne arithmétique. Il s’agit d’un exemple, pas d’une mesure de site.
Les bons seuils sont au maximum 2,5 secondes pour LCP, 200 millisecondes pour INP et 0,1 pour CLS. Évaluez séparément mobile et ordinateur. Un bon ordinateur ne compense pas un mobile défaillant, et les seuils sont identiques.
Examinez également la distribution. Un p75 tout juste bon peut cacher une part importante de visites lentes. Recherchez une concentration par région, modèle ou interaction avant de considérer le vert comme une fin en soi.
La comparaison de Google fournit le contexte méthodologique. Gardez toujours centile et population avec le nombre partagé.
Vérifier si le terrain correspond à l’URL
PSI tente d’afficher les données de l’URL et peut revenir à l’origine si les observations sont insuffisantes. Une origine combine protocole, nom d’hôte et port, pas le chemin complet ni tous les sous-domaines d’une organisation.
L’origine peut réunir plusieurs modèles, par exemple des produits lents et des articles rapides. Si le terrain décrit cet ensemble et le laboratoire un article, leur désaccord ne démontre pas une erreur.
Notez URL demandée et finale, appareil, périmètre et dates. « LCP mobile mauvais » ne dit pas quelle population souffre. Ne rebaptisez jamais une valeur d’origine en donnée d’URL dans un tableau de bord.
Si l’URL exacte manque, indiquez-le et gardez le contexte global à part. Le guide PageSpeed Insights précise où vérifier cette distinction.
Comprendre ce que les limitations simulent
Lighthouse peut estimer les performances sous contraintes de processeur et de réseau par simulation. D’autres configurations emploient d’autres méthodes. Lisez les paramètres : deux outils portant son nom ne fonctionnent pas forcément dans les mêmes conditions.
Ordinateur de développement, extensions, charge de fond et lieu du test peuvent influencer les résultats. Des exécutions varient sans changement de code. Conservez versions, stratégie, environnement et mesures individuelles avant de comparer des répétitions équivalentes.
L’état du cache compte aussi. Le laboratoire peut démarrer sans cache navigateur alors que les habitués réutilisent les fichiers, ou profiter d’un CDN chaud absent pour d’autres visiteurs. Précisez quelle couche est froide : vider le stockage local ne vide pas un cache en périphérie.
La simulation aide à retrouver du travail coûteux, sans promettre le résultat d’un téléphone précis. Choisissez d’autres scénarios selon l’audience plutôt que de répéter le profil par défaut jusqu’au vert.
Examiner la métrique qui explique l’écart
Pour LCP, comparez l’élément réellement le plus grand et son chemin de livraison. La largeur peut sélectionner une autre image ou un autre bloc. Distance, serveur, découverte et rendu changent le goulet. L’image d’ordinateur n’est pas forcément représentative du mobile.
Pour CLS, poursuivez après le chargement : intégrations tardives, publicités, consentement et retour arrière. Le test initial peut manquer les mouvements ultérieurs. Le titre déplacé peut être victime du conteneur supérieur plutôt que responsable.
Pour INP, testez des actions. Une navigation Lighthouse normale ne fournit pas la distribution INP de CrUX. TBT peut signaler une pression sur le thread principal au chargement, mais ne remplace pas INP. Des outils interactifs contrôlés mesurent bien la latence ; leurs limites sont celles du scénario et de sa couverture.
Reproduisez dans DevTools un menu, une recherche ou une option de produit. Un chargement propre peut précéder un premier clic coûteux. Gardez action, cible et trace pour permettre une reproduction.
Tenir compte de la fenêtre après publication
CrUX dans PSI couvre les 28 jours précédents avec une actualisation quotidienne. Juste après une correction, une grande partie décrit encore l’ancienne version. Nouveau laboratoire et terrain historique répondent alors à des questions temporelles distinctes.
Marquez la publication dans le suivi. Utilisez vos mesures récentes et des tests comparables pendant que de nouvelles visites alimentent la fenêtre publique. Ne promettez pas un changement après un délai fixe ni un échec sur la seule base d’une couleur inchangée.
L’audience peut également évoluer. Une campagne vers des connexions plus lentes modifie la distribution malgré un meilleur code. Comparez des segments si possible et reconnaissez l’incertitude du résultat agrégé.
Ajouter du RUM pour identifier la cause
Le suivi des utilisateurs réels, RUM, peut associer les métriques au modèle de page et à la version déployée. Préparez collecte, consentement, conservation et accès. N’envoyez ni comptes, ni valeurs de formulaires, ni URLs complètes contenant des paramètres sensibles.
La bibliothèque officielle web-vitals gère des détails importants du cycle de vie. Dans un projet qui installe et regroupe cette dépendance, ce module journalise localement les valeurs prises en charge, sans transmission.
import {onCLS, onINP, onLCP} from 'web-vitals';
function reportMetric(metric) {
console.log({
name: metric.name,
value: metric.value,
id: metric.id,
rating: metric.rating,
navigationType: metric.navigationType
});
}
onCLS(reportMetric);
onINP(reportMetric);
onLCP(reportMetric);Remplacez le journal par une collecte approuvée après avoir conçu le serveur. Une métrique peut être signalée plusieurs fois à mesure qu’elle évolue : définissez mise à jour et déduplication. Un callback n’est pas nécessairement une nouvelle visite. INP absent peut signifier absence d’interaction éligible ; ne le remplacez pas par zéro.
Votre RUM ne coïncidera pas forcément avec CrUX : navigateurs, échantillonnage, consentement, navigation et iframes diffèrent. Utilisez la version d’attribution si nécessaire et examinez les détails recueillis avant transmission.
Réserver chaque résultat à la décision qu’il permet
Pour une modification technique, reproduisez le parcours et démontrez l’amélioration à conditions comparables. Pour l’expérience des visiteurs, suivez le terrain avec période et périmètre. Pour Search, distinguez Core Web Vitals et note Lighthouse : celle-ci n’est pas une note de classement.
Choisissez une métrique, un modèle et un parcours répétable. Gardez la référence, modifiez la cause supposée et vérifiez fonctionnement et temps. Utilisez l’analyseur PageSpeed lorsqu’il est activé et les guides Core Web Vitals. Un écart expliqué doit conduire à une correction vérifiée.
