Pourquoi vos scores Lighthouse mobile sont-ils systématiquement plus bas que sur desktop ?

Pourquoi Lighthouse pénalise-t-il davantage le mobile que le desktop ?

La différence de score entre mobile et desktop n'a rien d'arbitraire. Lighthouse applique un throttling CPU sur les tests mobiles — concrètement, il bride volontairement la puissance de calcul pour simuler un appareil moyen de gamme.

L'objectif ? Reproduire les conditions réelles d'un utilisateur qui navigue depuis un smartphone en 4G, pas depuis un MacBook Pro connecté en fibre. Les processeurs mobiles sont moins puissants, la connexion plus variable, la batterie limitée. Le test reflète cette réalité terrain.

Qu'est-ce que le throttling CPU exactement ?

Le throttling CPU est une technique qui ralentit artificiellement le processeur lors du test Lighthouse. Par défaut, l'outil applique un facteur de ralentissement 4x sur mobile.

Résultat : un script JavaScript qui s'exécute en 100ms sur desktop prendra 400ms dans le test mobile. Ce délai impacte directement les métriques comme Total Blocking Time (TBT) ou Time to Interactive (TTI), qui pèsent lourd dans le score final.

Faut-il ignorer les scores desktop et se concentrer uniquement sur mobile ?

Depuis l'indexation mobile-first généralisée, Google crawle et évalue prioritairement la version mobile de votre site. Les scores desktop gardent un intérêt pour l'expérience utilisateur sur ordinateur, mais ils ne reflètent pas le prisme d'évaluation de Google.

En pratique, un site qui performe brillamment sur desktop mais s'effondre sur mobile est un site mal optimisé. L'inverse — bon sur mobile, moyen sur desktop — pose moins de problème pour le référencement. Le mobile dicte la règle du jeu.

• Les scores Lighthouse mobile intègrent un throttling CPU 4x pour simuler des conditions réelles
• Les appareils mobiles représentent la majorité du trafic web et sont le critère d'évaluation prioritaire de Google
• Un écart de 20-30 points entre mobile et desktop est normal et attendu
• Les métriques JavaScript-intensives (TBT, TTI) sont particulièrement impactées par le throttling
• Optimiser pour mobile améliore mécaniquement les performances desktop, l'inverse est rarement vrai

Cette déclaration est-elle cohérente avec les observations terrain ?

Absolument. Tout professionnel qui audite régulièrement des sites constate cet écart systématique entre les scores mobile et desktop. La déclaration de Martin Splitt valide ce qu'on observe depuis des années.

Le problème, c'est que beaucoup de clients ou décideurs découvrent PageSpeed Insights, voient un score desktop à 95 et un score mobile à 65, et crient au bug. Ce n'est pas un bug — c'est le reflet fidèle d'un site non optimisé pour les contraintes mobiles.

Quelles nuances faut-il apporter à cette règle ?

Le throttling 4x de Lighthouse est un standard arbitraire. Un iPhone 14 Pro sera plus performant qu'un smartphone Android d'entrée de gamme sorti en 2019. L'outil simule un appareil moyen, pas un flagship ni un bas de gamme.

Concrètement, si votre audience utilise majoritairement des appareils récents et des connexions stables, les scores Lighthouse mobile peuvent être plus pessimistes que la réalité terrain. Inversement, si vous ciblez des marchés émergents avec des appareils anciens et de la 3G instable, Lighthouse est peut-être encore trop indulgent. [A vérifier] avec les données réelles du Chrome User Experience Report (CrUX) pour votre domaine.

Dans quels cas cette règle ne s'applique-t-elle pas pleinement ?

Les sites desktop-only (applications métier, back-office, outils professionnels) peuvent légitimement ignorer les scores mobile si leur trafic est à 95% desktop. Mais soyons honnêtes : ces cas sont minoritaires.

Pour les sites grand public, e-commerce, médias, services — soit 90% du web — la performance mobile prime. Un score mobile catastrophique signale un problème structurel : JavaScript bloquant, images non optimisées, serveur lent, CSS critique absent. Ces problèmes impactent aussi le desktop, juste de manière moins visible.

Que faut-il faire concrètement pour améliorer les scores mobile ?

Prioriser le JavaScript. C'est lui qui tue les performances mobile via le throttling CPU. Chaque librairie tierce, chaque tag manager, chaque widget social alourdit le TBT. Auditez vos scripts, éliminez les dépendances inutiles, chargez en defer ou async tout ce qui n'est pas critique.

Optimiser les images devient encore plus crucial. Sur mobile, une image de 2Mo en JPEG charge déjà lentement — mais c'est le CPU qui doit ensuite la décoder et la rendre. Passez au WebP ou AVIF, dimensionnez correctement avec srcset, lazy-loadez tout ce qui est hors viewport initial.

Quelles erreurs éviter absolument ?

Ne pas tester uniquement sur votre iPhone 15 en wifi fibre. Utilisez les DevTools Chrome avec throttling activé, ou mieux encore, un vrai appareil Android moyen de gamme. L'écart entre votre environnement de développement et la réalité utilisateur est souvent abyssal.

Éviter de charger du CSS ou du JavaScript render-blocking pour des fonctionnalités secondaires. Le carrousel de la homepage, le chat bot, les animations fancy — tout ça peut attendre que le contenu principal soit affiché. Priorisez l'Above the Fold mobile.

Comment vérifier que mon site est correctement optimisé pour mobile ?

Comparez vos scores Lighthouse avec vos données CrUX réelles. Si vous passez le seuil des Core Web Vitals (LCP < 2.5s, FID < 100ms, CLS < 0.1) sur les vraies données terrain, vous êtes dans les clous — même si Lighthouse mobile râle.

Utilisez PageSpeed Insights qui combine les deux : score lab Lighthouse ET données field CrUX. Si l'écart est énorme, creusez. Un bon score lab mais des Core Web Vitals catastrophiques en field signale un problème de variabilité réseau ou device que vous ne reproduisez pas en test.

• Auditer et réduire le JavaScript bloquant (bundles trop lourds, librairies inutiles)
• Implémenter le lazy-loading sur toutes les images hors viewport initial
• Passer les images en WebP ou AVIF avec srcset adaptatif
• Extraire et inliner le CSS critique pour l'Above the Fold mobile
• Tester avec throttling CPU activé dans Chrome DevTools (option "4x slowdown")
• Valider les Core Web Vitals avec les données CrUX réelles de votre domaine