Lighthouse décrit un test exécuté dans des conditions définies, tandis que CrUX fournit des données agrégées issues de visites réelles éligibles. Ces deux sources ne mesurent pas nécessairement le même instant, la même population ni le même périmètre. Un écart n’implique donc pas automatiquement une erreur. Utilisez le laboratoire pour explorer une cause et vérifier une modification, puis le terrain pour suivre l’expérience observée à plus grande échelle, en conservant les dates et les limites de chaque source.
Deux questions différentes derrière deux rapports
Un audit de laboratoire répond à une question de scénario : que se passe-t-il lorsque cet outil charge cette page avec ce profil ? Cette observation peut être répétée et examinée dans le détail. Elle offre des diagnostics techniques utiles, mais ne prétend pas représenter toutes les visites possibles ni toutes les interactions qu’un utilisateur réalisera ensuite.
Les données de terrain répondent à une autre question : que montrent les visites incluses dans une collecte donnée ? Elles peuvent refléter une diversité de conditions difficile à reproduire sur un seul poste. Elles restent néanmoins soumises à un périmètre et à des critères de disponibilité. L’absence de données n’est pas une note favorable ou défavorable attribuée au site.
La méthodologie CrUX décrit les principes de cette collecte. Pour lire un résultat, conservez surtout le profil, la période et le niveau auquel il s’applique. Ces informations évitent de transformer une statistique agrégée en observation instantanée d’une page que vous venez de modifier.
Vérifier si les données concernent une URL ou une origine
Une URL désigne une page particulière, tandis qu’une origine rassemble un périmètre plus large. Si les données affichées concernent l’origine, elles ne doivent pas être présentées comme la mesure certaine de chaque page. Un résultat global peut masquer des différences entre un article léger, une fiche produit et un parcours interactif plus complexe.
Dans Onde, l’intégration CrUX cherche les données disponibles et indique le périmètre retourné. Lorsque la recherche utilise l’origine faute de données pour l’URL, l’interface doit le signaler explicitement. Gardez cette mention dans un compte rendu. La retirer pour simplifier une capture peut rendre la conclusion beaucoup plus large que ce que les données établissent.
Avant de comparer deux périodes, vérifiez également que le périmètre est resté cohérent. Une série sur une URL et une série sur l’origine ne constituent pas automatiquement un avant et après. Si vous changez de niveau d’observation, expliquez pourquoi et présentez les résultats comme des informations complémentaires plutôt que comme une continuité parfaite.
Lire la période de collecte avant la valeur
Un résultat de terrain agrégé peut inclure des visites antérieures à votre dernier déploiement. Il ne faut donc pas s’attendre à ce qu’une modification réalisée aujourd’hui soit immédiatement isolée dans la valeur affichée. Regardez les dates et documentez le calendrier des changements, surtout lorsque plusieurs versions du site ont coexisté pendant la période observée.
Dans l’intégration préparée pour Onde, un cache serveur peut également éviter de demander continuellement les mêmes informations au fournisseur. L’utilisateur doit distinguer la période décrite par les données de leur moment de consultation. Rafraîchir la page plusieurs fois n’équivaut pas à créer une nouvelle population de visites réelles.
Pour suivre une correction, conservez les résultats locaux datés et observez ensuite les données de terrain sur une période cohérente. Une évolution favorable peut soutenir votre analyse, mais elle ne prouve pas que la correction explique à elle seule tous les changements. Le trafic, le contenu et les conditions des visiteurs peuvent aussi varier.
Comprendre un percentile sans le convertir en moyenne
Un percentile décrit une position dans une distribution, pas une moyenne arithmétique. Lorsque vous lisez un p75, ne le présentez pas comme « le temps moyen de tous les visiteurs ». Utilisez le libellé exact et expliquez brièvement son rôle. Cette précision évite des comparaisons trompeuses avec une moyenne calculée sur quelques essais de laboratoire.
De même, ne comparez pas automatiquement le meilleur audit local à une statistique de terrain. Choisir seulement l’essai le plus favorable supprime la dispersion que vous avez réellement observée. Une petite série documentée offre un repère plus honnête pour comprendre le comportement de votre scénario, même si elle reste différente de la population CrUX.
Si vous préparez un tableau, séparez les colonnes par source et méthode. Indiquez « laboratoire, profil mobile, date » d’un côté et « terrain, p75, période, périmètre » de l’autre. Le tableau devient alors un outil d’analyse, plutôt qu’un classement où des nombres incompatibles seraient mis en concurrence sans explication.
Utiliser les diagnostics locaux pour chercher une cause
Lorsqu’une métrique mérite une investigation, le rapport local aide à examiner les ressources et les conditions du chargement. La cascade réseau peut montrer une ressource tardive ; le guide LCP aide à examiner le contenu principal. Ces pistes doivent être reliées à la page et au profil qui vous intéressent.
Pour une difficulté d’interaction, préparez un parcours précis et une trace adaptée. Le guide INP rappelle pourquoi le TBT d’un chargement n’est pas une mesure interchangeable avec l’INP des visites. Une métrique proche par son thème ne doit pas être utilisée comme substitut sans tenir compte de sa définition.
Pour une instabilité visuelle, examinez aussi les étapes après le premier écran. Le guide CLS propose une recette qui inclut contenu dynamique et interactions. Le terrain peut vous alerter sur une situation que votre premier essai local n’a pas rencontrée ; il faut alors élargir le scénario, pas déclarer le signal invalide.
Traiter correctement l’absence de données
Une page peut ne pas disposer de données CrUX accessibles dans le contexte demandé. Il faut afficher cette absence clairement, sans fabriquer un score ni interpréter le manque comme un excellent résultat. L’outil de laboratoire peut toujours être utile pour examiner le fonctionnement, mais il ne remplit pas artificiellement la case d’une statistique de terrain manquante.
Dans un rapport destiné à un client, écrivez « données de terrain indisponibles pour ce périmètre » plutôt que « Core Web Vitals validés » lorsque la vérification n’a pas été possible. Cette formulation distingue ce qui a été mesuré de ce qui reste inconnu. Elle protège la qualité du diagnostic sans empêcher de proposer des actions techniques concrètes.
Vous pouvez également préciser ce qui serait nécessaire pour compléter l’observation : attendre une période de collecte appropriée, examiner un périmètre disponible ou mettre en place une mesure adaptée au site avec les règles de confidentialité nécessaires. Ne présentez pas l’une de ces options comme déjà active si elle n’a pas été configurée et vérifiée.
Organiser un suivi après correction
Préparez une fiche de changement avec l’URL, le profil, la date, l’hypothèse et les fichiers ou composants modifiés. Réalisez plusieurs audits locaux avant et après dans des conditions proches. Notre protocole de comparaison aide à conserver cette traçabilité et à présenter les écarts sans promesse de gain universel.
Ajoutez ensuite les observations de terrain disponibles, en indiquant leur période. Si le résultat ne suit pas l’hypothèse, vérifiez d’abord le périmètre et le scénario avant de multiplier les corrections. Une page peut avoir été améliorée tandis que d’autres parcours de l’origine restent difficiles. La statistique globale ne permet pas toujours de distinguer ces situations.
Enfin, conservez une règle de suivi. Un budget de performance et des contrôles réguliers peuvent aider à repérer une régression technique. Les données de terrain complètent cette vigilance en montrant l’expérience collectée. L’ensemble fonctionne mieux lorsque chaque source conserve son rôle, plutôt que lorsqu’un score unique remplace toute l’analyse.
FAQ : rapprocher les deux types de données
Pourquoi Lighthouse est-il bon alors que CrUX est moins favorable ?
Les conditions, les visiteurs, les parcours et la période peuvent différer. Vérifiez également si CrUX concerne l’URL ou toute l’origine. L’écart mérite une investigation, pas une désignation automatique de la « bonne » source. Reproduisez des scénarios pertinents et recherchez les situations que votre audit initial n’avait pas couvertes.
L’absence de données CrUX signifie-t-elle que mon site est mauvais ?
Non. Elle indique que les données demandées ne sont pas disponibles dans ce contexte. Il ne faut en déduire ni une réussite ni un échec des métriques. Continuez le diagnostic avec les outils adaptés, tout en conservant la mention d’absence de données de terrain dans votre rapport et vos conclusions.
Puis-je utiliser les données de l’origine pour certifier une page ?
Elles donnent un contexte plus large, mais ne prouvent pas le comportement exact de chaque URL. Indiquez le périmètre et examinez la page séparément lorsque c’est nécessaire. Ne retirez pas cette distinction d’un résumé partagé : elle change la portée de ce que le lecteur peut raisonnablement conclure.
Un p75 est-il la moyenne des visiteurs ?
Non. Il représente un percentile de la distribution décrite par la source. Gardez ce nom dans les graphiques et les tableaux. Une moyenne de quelques essais locaux n’est pas automatiquement comparable à ce percentile de terrain. Les deux peuvent éclairer le diagnostic si leurs méthodes et leurs périodes restent explicites.
Combien de temps faut-il attendre après une correction ?
Il faut regarder la fenêtre de collecte de la source, pas appliquer une durée universelle à tous les outils. Vérifiez immédiatement le scénario local, puis suivez le terrain en tenant compte des dates et du périmètre. N’annoncez pas une validation définitive sur la base d’une statistique qui inclut encore un contexte antérieur à la modification.