# Un score Lighthouse excellent mais des Core Web Vitals terrain catastrophiques

> 98 sur 100 en local, un rapport d'expérience Search Console au rouge : l'écart entre un audit de laboratoire et les données réelles des visiteurs, expliqué.

- Auteur : Clément Hadrot
- Publié le : 2021-10-11
- Mis à jour le : 2021-10-11
- Catégorie : SEO &amp; GEO
- URL : https://wpmoderne.dev.wordpress-developpement.fr/seo/lighthouse-excellent-core-web-vitals-terrain-catastrophiques/

## L’essentiel

- Lighthouse mesure un seul chargement dans des conditions contrôlées et optimistes
- Le rapport d'expérience Search Console agrège des mois de visites réelles très variées
- Un réseau mobile lent ou un terminal ancien invisible en local expliquent l'essentiel de l'écart

Un développeur lance un audit Lighthouse sur la page d'accueil d'un site vitrine fraîchement optimisé : 98 sur 100 en performance, tous les indicateurs au vert, de quoi être satisfait du travail effectué. Pourtant, le rapport « Signaux Web essentiels » de Search Console affiche, pour la même URL, un statut « Médiocre » sur le First Input Delay, avec plusieurs milliers d'URL concernées. Comment un score aussi bon en local peut-il coexister avec une expérience aussi dégradée en conditions réelles ?

## Symptôme : deux sources qui semblent se contredire

Le réflexe naturel face à cet écart est de douter de l'un des deux outils, en général Search Console, jugé moins précis ou plus lent à se mettre à jour. En creusant la documentation de Google sur le sujet, la réponse est ailleurs : ces deux outils ne mesurent tout simplement pas la même chose, ni dans les mêmes conditions, ni sur le même échantillon.

## Diagnostic : ce que chaque outil mesure réellement

Lighthouse effectue un audit de laboratoire : un seul chargement de page, dans un environnement contrôlé, généralement avec une simulation de réseau et de processeur qui reste malgré tout plus favorable que les conditions réelles d'une bonne partie des visiteurs mobiles. Le rapport d'expérience de Search Console, lui, s'appuie sur le Chrome User Experience Report (CrUX), une base de données terrain agrégée à partir des visites réelles de millions d'utilisateurs Chrome ayant activé la synchronisation, sur une fenêtre glissante de 28 jours.

> L'essentiel à retenir : Lighthouse mesure un seul chargement dans des conditions contrôlées et optimistes ; Le rapport d'expérience Search Console agrège des mois de visites réelles très variées ; Un réseau mobile lent ou un terminal ancien invisible en local expliquent l'essentiel de l'écart

## La métrique la plus souvent responsable de l'écart

Sur ce cas précis, la métrique en cause était le First Input Delay, qui mesure le temps entre la première interaction d'un utilisateur (un clic, un appui) et la réponse effective du navigateur à cette interaction. Cette métrique dépend directement de la charge du processeur au moment de l'interaction, un facteur presque impossible à reproduire fidèlement en laboratoire : un audit Lighthouse ne simule jamais un utilisateur qui clique frénétiquement sur un menu pendant qu'un script tiers lourd bloque encore le fil principal.

Un examen du site avec l'onglet Performance des outils de développement Chrome, en simulant un processeur quatre fois plus lent, a permis de reproduire partiellement le problème : un script de tchat tiers, chargé de façon synchrone, bloquait le fil principal pendant près d'une seconde après le chargement initial, un délai invisible dans le score Lighthouse global mais très perceptible pour un visiteur qui tente d'interagir pendant cette fenêtre.

## Correctif appliqué

Le script de tchat tiers a été rechargé de façon asynchrone et différée après l'événement `load`, plutôt que de bloquer le rendu initial de la page :

```
window.addEventListener( 'load', function () {
    setTimeout( function () {
        var script = document.createElement( 'script' );
        script.src = 'https://widget-tchat-tiers.example.com/embed.js';
        document.body.appendChild( script );
    }, 3000 );
} );
```

Ce délai de trois secondes après le chargement complet laisse le fil principal disponible pour les interactions initiales de l'utilisateur, tout en garantissant que le widget de tchat reste disponible peu après pour ceux qui souhaitent réellement l'utiliser.

## Prévention pour la suite

Pour éviter de retomber dans le même piège de lecture, plusieurs réflexes ont été ajoutés au processus de recette de ce client :

- Ne jamais valider une optimisation de performance sur la seule base d'un score Lighthouse local.
- Consulter systématiquement le rapport d'expérience Search Console avant de conclure qu'une optimisation est suffisante.
- Garder en tête que ce rapport terrain met plusieurs semaines à refléter un changement récent, sans tirer de conclusion hâtive entre-temps.

> Un score de laboratoire parfait ne garantit rien sur l'expérience réelle des visiteurs les moins bien équipés ; c'est précisément cette population que les données terrain permettent de ne pas ignorer.

## En résumé

Lighthouse reste un outil précieux pour itérer rapidement pendant le développement, mais il ne remplace jamais les données terrain agrégées par Google sur de vrais visiteurs, avec de vrais appareils et de vraies conditions réseau. Les deux outils se complètent, à condition de comprendre qu'ils ne répondent pas à la même question.
