Score Lighthouse : comment dépasser 95 en mobile en 2026
Lighthouse est le standard 2026 pour mesurer la qualité technique d'un site web. Atteindre 95+ en mobile n'est plus optionnel : c'est ce qui sépare les sites qui se positionnent des sites qui rament.
Ce que mesure Lighthouse en 2026
Lighthouse est l’outil officiel de Google pour auditer la qualité technique d’un site web. Il mesure 4 dimensions :
- Performance : vitesse de chargement, fluidité, réactivité (LCP, INP, CLS, FCP, TBT)
- Accessibilité : conformité WCAG, lisibilité, navigation clavier
- Best Practices : sécurité (HTTPS), images optimisées, console errors
- SEO : meta-données, indexabilité, structured data basique
Chaque dimension est notée sur 100. Le score global est la moyenne pondérée.
Seuils Google :
- 0-49 : rouge (mauvais)
- 50-89 : orange (perfectible)
- 90-100 : vert (bon)
Mais en 2026, sur les requêtes concurrentielles, 90 ne suffit plus. Il faut viser 95+ sur les 4 dimensions pour battre les concurrents qui ont fait le travail. Cet article explique comment.
Pourquoi 95+ et pas 90+
Trois raisons pour pousser au-delà de 90.
Pondération Core Web Vitals. Depuis Core Update mars 2026, les Core Web Vitals (LCP, INP, CLS) pèsent davantage dans le positionnement. Un site à 92 et un site à 98 ne sont pas équivalents : le second a un avantage SEO concret sur les requêtes serrées.
Mobile-first index. Google indexe et classe en priorité la version mobile. Le Lighthouse mobile est le seul qui compte vraiment. Or il est plus difficile à optimiser que le desktop : connexion 4G, processeur moins puissant, taille écran réduite. Atteindre 95 mobile demande plus d’effort que 95 desktop.
Convergence concurrentielle. En 2026, beaucoup d’agences ont compris l’importance de Lighthouse. Vos concurrents directs ont monté leur score. Si vous restez à 75 quand ils sont à 95, l’écart se voit dans le positionnement.
Décomposition d’un mauvais score : les causes typiques
Un Lighthouse mobile à 65-75 (cas typique des PME romandes en 2026) cumule souvent les 5 problèmes suivants.
Problème 1 : Images trop lourdes
Symptôme : LCP > 4 secondes, score Performance bas.
Cause : images PNG/JPEG sans compression, sans format moderne (WebP/AVIF), sans lazy loading, sans dimensions déclarées.
Solution : convertir toutes les images en WebP ou AVIF (gain 30-50 % de taille), servir en responsive avec srcset, lazy load tout ce qui est sous la ligne de pli, déclarer width et height pour éviter le CLS.
Outils : Squoosh.app (compression manuelle), Imagify ou ShortPixel (auto pour WordPress), service Astro/Next.js (auto au build).
Problème 2 : JavaScript bloquant
Symptôme : TBT (Total Blocking Time) > 600 ms, INP dégradé.
Cause : scripts tiers chargés en synchrone (Google Tag Manager, Hotjar, chat widgets), bundle JavaScript principal trop gros (> 200 KB), pas de code splitting.
Solution : passer tous les scripts tiers en async ou defer. Code split le bundle principal en chunks logiques. Évaluer chaque script tiers : est-ce qu’il est vraiment utile ?
Erreur courante : charger Google Tag Manager sur 100 % du site juste pour tracker 3 events. Préférer du tracking direct sans GTM si pertinent.
Problème 3 : Polices web bloquantes
Symptôme : FOIT (Flash Of Invisible Text) en début de chargement, score Performance bas.
Cause : polices custom chargées en synchrone depuis Google Fonts ou Adobe Fonts.
Solution : font-display: swap dans @font-face, sub-setting des fonts (charger seulement les caractères utilisés).
Problème 4 : CSS bloquant en render
Symptôme : FCP (First Contentful Paint) > 1.8 s.
Cause : tout le CSS du site chargé en synchrone dans le <head>.
Solution : extraire le CSS critique (visible above the fold) en inline dans le HTML, charger le reste en non-bloquant.
Outils : Critters (Astro), criticalCSS (Next.js), penthouse.
Problème 5 : Plugins WordPress qui s’accumulent
Symptôme : score Performance < 60 même sur des sites simples.
Cause : 20-40 plugins WordPress chargés, chacun ajoutant 10-50 KB de JS et de la latence serveur.
Solution : audit des plugins, désactiver ceux non essentiels, remplacer les multi-plugins par des solutions natives. Ou migrer vers une stack moderne (cf. notre article WordPress SEO).
Les 9 actions concrètes pour passer de 70 à 95+
Action 1 : Audit de l’état actuel
PageSpeed Insights → entrez votre URL → notez les scores et opportunités identifiées par Lighthouse. Faire mobile et desktop. Mobile est ce qui compte.
Action 2 : Compression d’images
Première action à fort impact. Conversion WebP/AVIF systématique. Sur Astro/Next.js, c’est automatique via <Image>. Sur WordPress, Imagify ou ShortPixel font le job (CHF 5-10/mois).
Action 3 : Lazy loading
Pour toutes les images sous la ligne de pli : loading="lazy" natif. Sur les vidéos YouTube embed, utiliser lite-youtube-embed plutôt que l’embed standard.
Action 4 : Dimensions images déclarées
Toujours width et height sur chaque image, soit en HTML, soit en CSS aspect-ratio. Évite le CLS (décalage layout au chargement).
Action 5 : Code splitting JavaScript
Découper le bundle JS en chunks par route. Sur Next.js, c’est natif. Sur Astro, le JS est minimal par défaut (islands seulement). Sur WordPress avec un thème lourd, plus complexe.
Action 6 : Scripts tiers async ou defer
Tous les <script> non critiques en async ou defer. Évaluer la nécessité de chaque script tiers (chat widget, analytics, Google Tag Manager).
Action 7 : Polices optimisées
font-display: swap sur toutes les @font-face. Self-host si possible. Sub-setting des polices custom pour réduire la taille.
Action 8 : CSS critique inliné
Le CSS du premier viewport inliné dans le <head>. Le reste chargé en non-bloquant.
Action 9 : Schema.org pour le SEO Lighthouse
Le score SEO Lighthouse vérifie la présence de schema.org basique. Implémenter Organization, BreadcrumbList, Article au minimum.
Erreurs à éviter
Erreur 1 : optimiser uniquement le desktop. Beaucoup de PME testent uniquement le desktop et concluent « mon Lighthouse est à 95 ». Mobile reste à 60. Google classe sur le mobile.
Erreur 2 : mesurer une seule fois. Lighthouse varie selon les conditions (cache, réseau, charge serveur). Faire 3 tests et prendre la médiane.
Erreur 3 : ignorer les nouvelles métriques. INP a remplacé FID en 2024. Beaucoup d’articles datés ne parlent pas d’INP. Veiller à ce que votre audit utilise les métriques 2026.
Erreur 4 : score artificiellement gonflé par les retraits. Désactiver toutes vos fonctionnalités pour gonfler le score Lighthouse n’aide pas si votre site devient inutile. Garder l’expérience utilisateur en tête.
Ce que Voren livre
Tous les sites Voren sont livrés avec un score Lighthouse mobile mesuré au go-live — c’est notre standard de livraison :
- Site vitrine Essentiel : Lighthouse > 90 mobile + desktop
- Site vitrine Premium : Lighthouse > 95
- Site vitrine Sur mesure : Lighthouse > 95
- E-commerce : Lighthouse > 90 (sites e-commerce sont structurellement plus complexes à optimiser)
- Web app : Lighthouse > 85 selon complexité
Stack par défaut : Astro 5 (sites éditoriaux) ou Next.js 15 (interactifs) + images optimisées + scripts async + schema.org + CSS critique inliné.
Pour aller plus loin
Demander un audit Lighthouse gratuit : diagnostic complet de votre site actuel et plan d’action en 7 jours.
Voir notre service Site vitrine : Lighthouse 90-95+ visé et mesuré au go-live.
Voir notre article Core Web Vitals : comprendre les 3 métriques qui pondèrent Lighthouse Performance.