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

Pourquoi cette différence de score n'est-elle pas un problème de mesure ?

La déclaration de Martin Splitt coupe court à une idée reçue tenace : non, Lighthouse n'est pas « plus sévère » sur mobile par caprice algorithmique. Les scores reflètent une réalité physique — les processeurs mobiles disposent de moins de puissance de calcul, et les connexions réseau sont souvent instables ou limitées en bande passante.

Concrètement, un site qui charge en 1,2 seconde sur un desktop i7 avec fibre peut mettre 4,5 secondes sur un Moto G4 en 3G lent. Lighthouse simule ces conditions réelles, d'où l'écart de score parfois brutal. Ce n'est pas une erreur de mesure, c'est le reflet de l'expérience utilisateur majoritaire.

Qu'est-ce que le « plus petit dénominateur commun » dans ce contexte ?

Le mobile représente le scénario le plus contraignant : CPU limité, réseau variable, batterie à économiser. Si votre site performe en mobile, il performera forcément en desktop. L'inverse n'est pas vrai.

Google applique donc le principe du mobile-first indexing : l'index se construit sur la version mobile, et les Core Web Vitals mesurés en conditions réelles proviennent majoritairement du trafic mobile. Optimiser pour desktop seul revient à ignorer 60-70 % de vos visiteurs réels — et l'essentiel du signal de ranking.

Les scores Lighthouse desktop sont-ils alors inutiles ?

Pas inutiles, mais moins représentatifs du terrain. Un score desktop de 95 peut masquer un mobile catastrophique à 42. Or c'est le mobile qui compte pour l'indexation, le CrUX, et donc le ranking.

Le desktop reste pertinent pour diagnostiquer certains problèmes structurels (JavaScript bloquant, CSS non optimisé) qui affectent les deux plateformes. Mais la vraie validation se fait sur mobile — c'est là que vos faiblesses apparaissent sans pitié.

• Les scores mobiles reflètent des contraintes matérielles réelles, pas un biais algorithmique.
• Le mobile constitue le dénominateur commun pour l'indexation et le ranking Google.
• Un bon score desktop ne garantit rien si le mobile est médiocre — l'inverse est vrai.
• Les Core Web Vitals terrain proviennent majoritairement du trafic mobile, c'est ce signal qui compte.
• Optimiser pour mobile couvre automatiquement le desktop, la stratégie inverse échoue souvent.

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

Absolument. Tous les SEO qui auditent régulièrement voient l'écart systématique entre scores mobile et desktop — souvent 20 à 40 points de différence. La déclaration de Splitt confirme ce que le terrain montre depuis des années : le mobile est structurellement plus exigeant.

Soyons honnêtes : beaucoup de sites affichent un score desktop honorable (70-85) et s'effondrent en mobile (30-50). Ce n'est pas un hasard, c'est le révélateur d'une stack technique pensée desktop-first. Les images non optimisées, le JavaScript lourd, les polices web non préchargées — tout cela passe « à peu près » sur desktop et devient rédhibitoire sur mobile.

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

La déclaration reste générale. Elle ne précise pas quel écart de score est acceptable — 10 points ? 30 points ? Google ne donne aucun seuil. [À vérifier] sur vos propres données CrUX : un écart trop important peut signaler un problème structurel même si le score mobile reste « vert ».

Autre nuance : certains sites desktop-only (outils SaaS B2B, applications métier) ont un trafic mobile marginal. Pour eux, prioriser le mobile n'a aucun sens business. Mais attention — Google indexe quand même la version mobile par défaut. Il faut alors s'assurer que la version mobile existe et reste fonctionnelle, même si elle n'est pas la cible principale.

Dans quels cas cette logique mobile-first peut-elle coincer ?

Sur des sites à forte composante interactive ou applicative. Un CRM web, un éditeur de photos en ligne, une plateforme de data visualisation — ces outils sont conçus pour desktop, avec souris, grands écrans, puissance CPU. Forcer une optimisation mobile peut dégrader l'expérience utilisateur principale.

Dans ces cas, il faut arbitrer entre signal SEO et UX réelle. Une solution hybride : version mobile fonctionnelle mais simplifiée, avec redirection vers desktop pour les features avancées. Ou accepter un score mobile médiocre si le trafic organique mobile est négligeable — mais documenter ce choix stratégique pour éviter les fausses alertes en audit.

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

Commencez par identifier les goulots d'étranglement CPU : JavaScript trop lourd, animations complexes, frameworks côté client mal optimisés. Lighthouse vous donnera les « Opportunities » et « Diagnostics » — ciblez en priorité ceux qui ont le plus d'impact en secondes gagnées.

Ensuite, optimisez les ressources réseau : compressez les images (WebP, AVIF), lazy-loadez tout ce qui est hors viewport initial, préchargez les polices critiques. Un site qui charge 3 Mo de ressources en mobile, c'est rédhibitoire — visez moins de 1 Mo pour le First Contentful Paint.

Quelles erreurs éviter absolument ?

Ne testez pas uniquement sur votre iPhone 15 Pro en WiFi. Lighthouse simule un Moto G4 en 4G lent — c'est très loin de votre setup quotidien. Testez sur des devices réels mid-range, avec throttling réseau activé.

Autre piège : se concentrer uniquement sur le score global et ignorer les métriques individuelles. Un LCP catastrophique à 6 secondes peut coexister avec un score « orange » de 65. Ciblez les métriques qui plombent l'expérience réelle (LCP, CLS, TBT), pas juste le chiffre global.

Comment vérifier que votre stratégie mobile-first porte ses fruits ?

Comparez vos données CrUX terrain vs. Lighthouse lab. Si votre Lighthouse mobile est à 55 mais votre CrUX réel montre 80 % d'utilisateurs en « Good », c'est que vos visiteurs ont des devices plus puissants que le Moto G4 simulé — vous êtes probablement OK.

Inversement, un Lighthouse à 70 mais un CrUX catastrophique signale un problème : conditions réseau réelles pires que la simulation, ou trafic sur devices encore plus faibles. Auditez alors votre mix de trafic : pays, opérateurs, devices. Les Core Web Vitals sont segmentables dans la Search Console.

• Auditez Lighthouse mobile en priorité, desktop en second.
• Ciblez LCP, CLS et TBT — ce sont les métriques qui comptent pour le ranking.
• Testez sur devices mid-range réels, pas uniquement sur vos flagships perso.
• Compressez images et différez tout JavaScript non-critique — moins de 1 Mo pour le viewport initial.
• Surveillez CrUX terrain vs. Lighthouse lab pour valider que vos optimisations se traduisent en expérience réelle.
• Documentez vos choix si votre site est desktop-only par design — assumez l'arbitrage plutôt que de subir l'alerte.