Comment tester la Core Web Vitals avec Lighthouse en mode mobile

Vous ouvrez la console, vous lancez un audit, et le score tombe : 34 sur 100. Vous relancez en cochant « Desktop », et là, magie, vous êtes à 89. Même page, même code, deux scores qui n'ont rien à voir. Ce n'est pas un bug. C'est exactement ce qui se passe quand on teste les Core Web Vitals avec Lighthouse en mode mobile, et c'est précisément ce que la plupart des gens ratent.

La question m'arrive à chaque audit que je fais pour des clients : « pourquoi mon score PageSpeed est mauvais alors que mon site est rapide sur mon MacBook ? » La réponse tient en un mot : l'émulation. Lighthouse mobile ne teste pas votre site sur votre connexion fibre. Il le teste sur un téléphone milieu de gamme imaginaire, avec un réseau lent et un processeur bridé. Et c'est très bien ainsi, parce que c'est de cette façon que la majorité de vos visiteurs vous voient vraiment.

Pourquoi tester les Core Web Vitals en mode mobile change tout

Lighthouse par défaut tourne en mobile. Ce n'est pas un hasard. Quand vous ouvrez les DevTools de Chrome et que vous allez dans l'onglet Lighthouse, le preset sélectionné est « Mobile » — pas « Desktop ». La plupart des gens ne le remarquent même pas, puis s'étonnent que le score soit si bas.

Ce que fait le mode mobile, concrètement : il émule un appareil aux caractéristiques modestes, applique une limitation du CPU (le téléphone simulé est plusieurs fois plus lent que votre machine de dev), et bride le réseau pour simuler une connexion mobile médiocre. Résultat : tout ce qui prend 200 ms sur votre desktop peut en prendre 800 ou 1000 sur le mobile simulé.

Ce que le throttling simule pour vous

Le throttling de Lighthouse n'est pas une science exacte, mais il vise à reproduire un contexte réaliste : un téléphone d'entrée ou de milieu de gamme, quelques années au compteur, sur une 4G correcte mais pas parfaite. C'est une hypothèse. Elle est grossière, mais elle est utilement grossière.

J'ai vu des sites passer de « bon score » à « catastrophe » juste en basculant le preset. Un client avait un LCP de 1,9 s en desktop et de 6,4 s en mobile. Le serveur répondait en 80 ms dans les deux cas. La différence venait entièrement du rendu côté client : un bundle JavaScript trop lourd qui bloquait le thread principal, invisible sur une machine rapide, catastrophique sur un CPU bridé.

Lancer le mode mobile pas à pas

1. Ouvrez votre page dans Chrome, puis les DevTools (F12 ou clic droit → Inspecter).
2. Allez dans l'onglet Lighthouse. Si vous ne le voyez pas, cliquez sur les flèches « » pour afficher plus d'onglets.
3. Vérifiez que le preset « Mobile » est bien coché. S'il ne l'est pas, cochez-le et laissez-le coché.
4. Choisissez les catégories à auditer. Pour les Core Web Vitals, « Performance » suffit, mais cochez aussi « Accessibilité » et « SEO » si vous voulez tout voir.
5. Lancez l'audit. Comptez une trentaine de secondes.

Variante CLI, pratique pour scripter :

lighthouse https://votre-site.fr --preset=desktop --output=json

Sans --preset=desktop, la commande tourne en mobile par défaut. C'est cohérent avec le comportement des DevTools : le mobile est le mode de référence, pas l'exception.

Lighthouse mobile face aux Core Web Vitals réels

Voici le point qui fâche. Votre score Lighthouse mobile n'est pas votre score Core Web Vitals. Ce sont deux choses distinctes, mesurées différemment, et confondre les deux mène à optimiser pour la mauvaise cible.

Critère	Lighthouse (labo, mobile)	Core Web Vitals de terrain
Source des données	Un chargement simulé, une seule page	Les visites réelles de vos utilisateurs
Environnement	Appareil et réseau émulés	Vrais téléphones, vraies connexions
Interaction prise en compte	Faible (pas de vraie session)	Oui, l'INP provient des interactions réelles
Reproductibilité	Élevée : mêmes conditions à chaque run	Faible : dépend du trafic et de l'audience
Utilité	Diagnostiquer, débuguer	Décider si le site est réellement rapide

Le CLS et le LCP se mesurent correctement en labo. Le décalage de mise en page, par exemple, est reproductible : soit un élément bouge au chargement, soit il ne bouge pas. Un CLS de 0,25 détecté par Lighthouse mobile sera très probablement confirmé sur le terrain.

L'INP, c'est une autre histoire. Interaction to Next Paint mesure le délai entre une interaction utilisateur (clic, tap, saisie) et la réaction visuelle. Or Lighthouse ne simule aucune interaction réelle. Il ne peut donc pas produire un INP crédible. Il vous donnera des indices — JavaScript lourd, longues tâches, thread principal saturé — mais jamais le chiffre que Google utilise dans son classement.

Pourquoi votre score mobile et votre INP divergent

J'ai eu le cas l'année où j'ai commencé à prendre ce sujet au sérieux : un site e-commerce avec un score Lighthouse mobile de 92, impeccable, et un INP de terrain médiocre. Les clients se plaignaient que « ça rame quand on clique sur les filtres ». Le labo ne voyait rien, parce que personne ne cliquait dans le labo. La vraie interaction — un filtre qui déclenchait un recalcul lourd sur une liste de 400 produits — restait invisible.

La leçon est simple : Lighthouse mobile vous dit où chercher. Le terrain vous dit si vous avez trouvé. Confondre les deux, c'est comme réviser un examen en relisant le sommaire.

Interpréter un écart mobile/desktop sans se tromper

Un écart entre les deux presets n'est pas anormal en soi. Il devient intéressant à partir d'un certain seuil. Dans ma pratique, un écart de 10 à 20 points est courant et généralement tolérable. Au-delà de 30 points, il y a presque toujours une cause identifiable.

Les causes que je rencontre le plus souvent

• JavaScript lourd. Le CPU bridé encaisse mal les gros bundles. C'est la cause numéro un, de loin.
• Images non optimisées. En réseau bridé, une image de 800 Ko devient dramatique. Le LCP explose.
• Polices web bloquantes. Le rendu attend la police ; sur mobile, l'attente se paie en secondes.
• Scripts tiers. Un seul tag de suivi mal placé peut coûter 1 000 ms sur le mobile simulé, sans qu'on s'en rende compte en desktop. Et il y en a rarement un seul.

L'ordre importe. Optimiser les images avant d'avoir identifié la cause réelle, c'est perdre du temps. Le rapport Lighthouse mobile vous dit quoi corriger, par ordre d'impact. Lisez-le plutôt que de foncer sur la première chose qui vous semble lente.

Faut-il optimiser pour le labo ou pour le terrain ?

Les deux, mais pas de la même façon. Le labo sert à diagnostiquer et à éviter les régressions. Le terrain sert à valider l'expérience réelle. Une page peut avoir un score parfait et une mauvaise expérience utilisateur — c'est rare mais c'est possible.

Ma règle : si le labo est bon et le terrain mauvais, cherchez du côté des interactions et des scripts tiers. Si le terrain est bon et le labo mauvais, vous avez probablement un site correct sur les vraies machines de vos visiteurs, et le labo est juste plus pessimiste que la réalité. Ne vous acharnez pas.

Automatiser les tests mobile avec Lighthouse CI

Un audit manuel une fois par trimestre ne sert à peu près à rien. Les régressions de performance s'installent à chaque déploiement, une petite brique après l'autre. Au bout de six mois, on ne reconnaît plus le site.

Lighthouse CI résout ce problème. Il lance Lighthouse à chaque build, en mobile par défaut, et compare le résultat aux runs précédents. On peut fixer des budgets — un LCP maximal, un CLS maximal — et faire échouer la CI si on les dépasse.

Configuration minimale, dans un fichier .lighthouserc.json :

{
  "ci": {
    "collect": {
      "url": ["https://votre-site.fr/"],
      "settings": {
        "preset": "mobile"
      }
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.8 }]
      }
    }
  }
}

Le "preset": "mobile" n'est pas obligatoire — c'est déjà le comportement par défaut — mais l'écrire explicitement évite les surprises si un collègue passe derrière et modifie le fichier.

Ce que ça m'a coûté, honnêtement ? Trois heures de mise en place la première fois, à patauger dans la doc et à comprendre pourquoi un run passait localement et échouait en CI. Sur un run en CI, le throttling est appliqué de façon légèrement différente selon la machine. Il faut accepter une petite marge de tolérance, sinon on passe son temps à relancer des builds vertes devenues rouges pour dix points de score.

Un audit par page ou un audit global ?

Les deux. Lighthouse travaille sur une URL à la fois. Pour un site de 50 pages, auditez une sélection représentative : home, une catégorie, une page produit, une page panier. Cherchez le pattern, pas l'exhaustivité. Si trois pages sur quatre ont le même problème, il est probablement global.

Ce que le mode mobile ne vous dira pas

Reste une limite qu'aucun réglage ne corrige. Lighthouse mobile mesure un chargement unique sur une page unique. Il ne navigue pas, ne clique pas, ne fait pas défiler. Tout ce qui se passe après le premier affichage lui échappe.

Le CLS est particulièrement piégeux sur ce point. Un décalage qui survient après un délai — une bannière cookie qui apparaît au bout de deux secondes, une publicité qui se charge tard — peut passer complètement inaperçu dans un audit de labo qui ne dure que quelques secondes.

Le mode mobile de Lighthouse n'est donc pas un juge, c'est un détecteur. Il repère des problèmes réels, il en rate d'autres, et il vous donne une photo à un instant précis. Le terrain, lui, filme en continu. C'est la combinaison des deux qui permet de tenir un site rapide dans la durée — pas l'un, pas l'autre.

Et si vous ne devez retenir qu'une chose : le prochain mauvais score mobile que vous verrez, ne cherchez pas d'abord à faire remonter le chiffre. Cherchez pourquoi il est bas. Le chiffre suivra.