Score Lighthouse 90+ : la méthode
WebFlowr expliquée
Comment nous obtenons systématiquement un score Lighthouse supérieur à 90 sur chaque projet — sans sacrifier le design, sans compromis sur l'expérience utilisateur. Workflow, outils, erreurs à éviter.
Lead Developer · 5 mai 2026 · Mis à jour le 4 juin 2026
1.Ce que Lighthouse mesure vraiment — et ce que beaucoup confondent
Il y a quelques semaines, un client nous envoie son site pour audit avant refonte. Belle maquette, contenu bien rédigé, identité visuelle soignée. On lance le test Lighthouse mobile. Score : 31.
Trente et un sur cent. Un site vitrine neuf, livré six mois plus tôt par une agence. La page d'accueil pesait 14 Mo. Une seule image hero représentait 7 Mo à elle seule. Dix-neuf scripts tiers s'exécutaient dès le chargement — dont quatre pour un chatbot que le client n'utilisait plus depuis un an et demi.
Avant d'aller plus loin, précisons ce que Lighthouse mesure réellement. L'outil développé par Google évalue cinq dimensions : Performance, Accessibilité, Bonnes pratiques, SEO, et PWA. Quand on parle de "score Lighthouse", on fait presque toujours référence au score de performance — le seul qui intègre les Core Web Vitals (LCP, INP, CLS) dans ses métriques.
Ce score est calculé en condition simulée : mobile émulé, connexion 4G lente, CPU throttlé à 4x. C'est volontairement pénalisant. L'objectif est de révéler les problèmes que vos vrais visiteurs mobiles rencontrent — et ils sont nombreux dans la majorité des secteurs à représenter plus de la moitié du trafic.
Lighthouse simule une expérience mobile dégradée volontairement. Un score de 90+ dans ces conditions signifie que vos vrais visiteurs ont une expérience très fluide. Un score de 31 signifie que vous perdez des prospects avant même qu'ils aient lu votre offre.
2.Pourquoi la plupart des sites font des scores médiocres
On audite régulièrement des sites pour nos clients, souvent avant une refonte ou une migration. Ce qui frappe, c'est la récurrence des mêmes problèmes — quelle que soit la technologie utilisée, quelle que soit la taille de l'entreprise.
Des images traitées comme des décors
C'est de loin la cause numéro un. Lors d'un audit récent, on a trouvé une image héro de 6 Mo affichée sur une largeur de 1200 pixels. En JPEG. Sans dimensions définies dans le HTML. Cette seule image expliquait un LCP de 8,4 secondes. Après conversion en WebP et redimensionnement, le LCP est passé à 1,9 seconde. Aucune autre modification.
Un buffet de scripts tiers
Analytics, chatbot, heatmap, pixel Facebook, tag Google Ads, widget avis, bouton partage réseaux sociaux… Chacun de ces scripts s'exécute au chargement, mobilise le CPU, retarde l'interactivité. Sur un site que nous avons audité l'année dernière, 23 scripts tiers se chargeaient sur la page d'accueil. Cinq étaient encore utilisés. Les dix-huit autres étaient des reliquats d'anciennes campagnes, laissés là "au cas où".
Des polices chargées par habitude
L'appel Google Fonts classique — une balise link dans le <head> — génère deux requêtes supplémentaires et bloque le rendu sur les connexions lentes. On voit encore des sites charger six variantes d'une police (Thin, Light, Regular, Medium, SemiBold, Bold) quand deux suffiraient largement.
Des animations pensées pour le portfolio
Certaines transitions et animations sont magnifiques sur l'écran du designer. Sur un smartphone d'entrée de gamme avec CPU limité, elles provoquent des drops de framerate perceptibles et dégradent l'INP. La beauté ne compense pas la frustration.
3.La performance commence avant d'écrire la moindre ligne de code
La plupart des agences traitent la performance comme une option — quelque chose qu'on règle avec un plugin ou une passe de compression après coup. Le site est livré, Lighthouse donne 58, on compresse quelques images, on ajoute un cache, on espère que ça suffira.
Chez WebFlowr, on a une conviction différente : un site lent se fabrique dès le premier wireframe. Et ça se prévient de la même façon.
Chaque élément qu'on ajoute à une page a un coût. Une animation, une police supplémentaire, un widget de réservation tiers, une vidéo en autoplay — chacun de ces choix se traduit en octets, en requêtes réseau, en temps CPU. Avant de les intégrer, on pose une question simple : est-ce que cette ressource améliore réellement l'expérience de l'utilisateur ? Ou est-ce qu'elle ne sert que l'ambition esthétique du projet ?
Si la réponse n'est pas clairement "oui", l'élément n'est pas intégré. C'est aussi simple et aussi difficile que ça.
Conseil WebFlowr
Vous voulez savoir où en est votre site ?
WebFlowr réalise un audit de performance complet et gratuit en 48h.
4.Étape 1 — Architecture légère : ce qu'on refuse d'emblée
Un score Lighthouse élevé commence par une architecture qui ne se batte pas contre elle-même. Concrètement, ça signifie limiter la surface — moins de composants, moins de dépendances, moins de couches techniques.
Sur chaque projet Next.js, on part d'une base stricte. On évalue chaque bibliothèque ajoutée à l'arbre des dépendances : quel est son poids dans le bundle ? Peut-on faire la même chose nativement ? Une règle simple guide ces choix — si la feature peut être implementée sans installer un nouveau package, on ne l'installe pas.
- Zéro composant UI générique pour des éléments qu'on peut créer en 20 lignes
- Zéro bibliothèque d'animation si CSS suffit pour l'effet voulu
- Zéro police Google Fonts si une police système peut faire le travail
- Zéro widget tiers sans audit préalable de son impact sur l'INP
Cette discipline peut sembler excessive. Elle ne l'est pas. Sur un site vitrine livré avec cette approche, le bundle JavaScript initial fait généralement entre 80 et 140 Ko (gzippé) — contre 400 à 800 Ko sur des projets construits avec moins de rigueur.
5.Étape 2 — Images : le chantier le plus rentable de tous
Les images représentent en moyenne 60 à 70 % du poids d'une page web. C'est le levier numéro un de la performance, et c'est aussi celui qui génère le retour sur investissement le plus rapide. On a vu des gains de 30 points de score Lighthouse uniquement grâce à des optimisations d'images, sans toucher à une seule ligne de JavaScript.
Conversion systématique en WebP ou AVIF
WebP offre en moyenne une réduction de 25 à 35 % par rapport au JPEG pour une qualité visuelle équivalente. AVIF va encore plus loin — 40 à 50 % — mais sa compatibilité navigateur est plus récente. Sur nos projets Next.js, le composantImagegère automatiquement la conversion et le format selon le navigateur. Sur Webflow, on exporte toutes les sources en WebP avant upload.
Srcset et dimensions adaptées
Une image de 3000 pixels chargée sur un écran mobile de 390 pixels, c'est 57 fois plus de pixels que nécessaire. On génère systématiquement des srcset adaptés aux breakpoints réels du site — mobile, tablette, desktop — et on définit les attributs width et height sur chaque balise image pour éliminer les déplacements de mise en page (CLS).
Lazy loading et priorité explicite
Toutes les images sous le fold sont chargées en différé avec loading="lazy". L'image hero, elle, reçoit fetchpriority="high" pour que le navigateur la traite en priorité absolue — c'est souvent l'élément LCP, et ce seul attribut peut améliorer le LCP de 200 à 400 ms.
video en autoplay sans muted ni playsinline pour une animation décorative. La vidéo bloque sur iOS, force un chargement complet du fichier et détruit le score mobile. Utilisez un WebP animé ou une animation CSS à la place.6.Étape 3 — Polices et JavaScript : les suspects silencieux
Polices web
La méthode classique — un lien Google Fonts dans le <head> — déclenche deux requêtes réseau séquentielles avant même que le texte ne s'affiche. On recommande de passer en fonts auto-hébergées (fichiers WOFF2 copiés en local) ou, pour Google Fonts, d'utiliser font-display: swap avec un préchargement explicite. On limite aussi les variantes : Regular + Bold couvrent 95 % des besoins. Thin, Light, Medium, ExtraBold — si personne ne les réclame dans les maquettes, ils ne sont pas chargés.
JavaScript
Chaque kilo-octet de JavaScript a un coût double : le téléchargement et le parsing. Sur un CPU mobile throttlé, parser 300 Ko de JS peut prendre 2 à 3 secondes. Nos règles sont simples : tout ce qui n'est pas critique pour l'affichage initial est chargé en différé. Les scripts tiers (analytics, chat, maps) sont initialisés après le premier événement utilisateur — un scroll, un clic, un mouvement de souris — plutôt qu'au chargement de la page.
Conseil WebFlowr
strategy="lazyOnload" sur le composant Script retarde l'exécution après le chargement complet de la page. Pour Google Analytics, on préfère charger au premier événement utilisateur via un event listener — le tag ne perd aucune session, et l'INP s'améliore souvent de 50 à 100 ms.7.LCP, INP, CLS : nos pratiques par métrique
Les Core Web Vitals sont les métriques que Google utilise dans ses signaux d'expérience de la page. Contrairement au score Lighthouse global, ils sont mesurés sur vos vrais visiteurs via le Chrome User Experience Report. Ce que vous voyez dans PageSpeed Insights avec l'étiquette "Données terrain" — c'est ça qui compte pour le classement.
| Métrique | Cible | Causes fréquentes | Notre approche |
|---|---|---|---|
| LCP Largest Contentful Paint | ≤ 2,5 s | Image hero non préchargée · TTFB > 800 ms · CSS render-blocking | fetchpriority="high" sur le hero · CDN · suppression des render-blockers |
| INP Interaction to Next Paint | ≤ 200 ms | Tâches JS > 50 ms · gestionnaires d'événements lourds · scripts tiers | Fragmentation des tâches · requestIdleCallback · scripts tiers en defer |
| CLS Cumulative Layout Shift | ≤ 0,1 | Images sans dimensions · polices web swap brutal · blocs publicitaires | width + height systématiques · font-display: optional · skeleton loaders |
Un point important sur le CLS : ce n'est pas seulement une question d'images sans dimensions. Les polices web qui s'affichent avec un délai, les embeds (cartes, vidéos, iframes) sans hauteur réservée, les bannières cookies qui poussent le contenu vers le bas au chargement — tout ça contribue au CLS. On règle ces problèmes en phase de design, pas après la livraison.
LCP mesure la rapidité de chargement. INP mesure la réactivité. CLS mesure la stabilité visuelle. Les trois doivent être dans le vert pour que Google considère votre page comme offrant une bonne expérience.
Vos Core Web Vitals sont dans le rouge ?
WebFlowr identifie les causes exactes et les corrige — audit inclus.
8.Les outils de notre workflow
On ne mesure jamais la performance avec un seul outil. Chacun a ses biais : Lighthouse simule, PageSpeed Insights agrège des données passées, Chrome DevTools analyse en temps réel. La bonne lecture vient du croisement de plusieurs sources.
| Outil | Usage | Ce qu'il révèle |
|---|---|---|
Lighthouse Chrome DevTools | Audit laboratoire | Score global, détail par métrique, recommandations priorisées. Point de départ indispensable. |
PageSpeed Insights pagespeed.web.dev | Données terrain réelles | Croise les données CrUX (vrais utilisateurs) avec le labo. Seul outil qui montre vos CWV réels. |
Chrome DevTools Intégré Chrome | Analyse réseau | Cascade de chargement, tâches longues, blocages de rendu. Indispensable pour diagnostiquer le LCP. |
Search Console Rapport CWV | Suivi continu | Tendances sur 28 jours, segmentation par groupe de pages. C'est ici que Google juge votre site. |
WebPageTest webpagetest.org | Tests avancés | Filmstrip seconde par seconde, waterfall, comparaisons multi-locales. Pour les diagnostics complexes. |
9.Notre checklist avant livraison
Avant chaque mise en production, on passe cette liste point par point. Elle n'est pas exhaustive — un audit complet couvre bien plus de choses — mais elle évite 95 % des problèmes qu'on rencontre habituellement à la livraison.
- Images converties en WebP ou AVIF avec srcset responsive
- Lazy loading actif sur toutes les images sous le fold
- Image hero préchargée avec fetchpriority="high"
- Polices chargées en sous-ensembles (subset) — pas de famille complète
- font-display: swap ou optional sur toutes les polices web
- Zéro script tiers non audité et non justifié
- JavaScript non-critique chargé en differ ou async
- Dimensions width + height définies sur toutes les images
- LCP inférieur à 2,5 s (simulé mobile 4G — Lighthouse)
- INP inférieur à 200 ms (aucune tâche JS > 50 ms)
- CLS inférieur à 0,1 (test scroll complet)
- Score Lighthouse mobile ≥ 90 sur URL de production
Un seul point non coché peut suffire à faire passer un site de 92 à 71. Le plus fréquent en fin de projet : l'image hero non optimisée ajoutée au dernier moment par le client, après notre première validation. On a donc instauré une règle : tout nouveau media ajouté après validation passe systématiquement par notre pipeline d'optimisation avant publication.
10.Faut-il vraiment viser 100/100 ?
La question revient régulièrement. La réponse courte : non.
Un score de 100 est possible sur des pages très simples — une landing page statique sans image, sans police web, sans JavaScript. Mais sur un site vitrine avec un design soigné, des animations utiles et quelques outils marketing essentiels, viser 100 impose des compromis qui nuisent à l'expérience.
Vous pouvez gagner 3 points en supprimant une police web — mais le site ressemblera à une page des années 2000. Vous pouvez en gagner 2 de plus en désactivant vos animations d'entrée — mais l'impression de qualité disparaît. À quel moment un score meilleur sur un outil interne justifie-t-il une expérience dégradée pour vos vrais visiteurs ?
Notre position est claire : un site à 93 avec une expérience soignée, des animations utiles et un design premium vaut infiniment plus qu'un site à 100 dégradé pour impressionner dans un rapport. La performance est au service de l'expérience utilisateur et de la conversion — pas une fin en soi.
Notre objectif n'est pas le score parfait. C'est un site rapide, agréable, qui convertit. Si ces objectifs sont atteints à 93, c'est une réussite. La cible est ≥ 90 sur mobile — tout le reste est optimisation marginale.
11.Résultats observés après optimisation
Voici quelques exemples tirés de projets récents — anonymisés, mais représentatifs de ce qu'on observe régulièrement lors de refontes ou d'optimisations de sites existants.
Scores Lighthouse mobile — exemples issus de projets anonymisés
Site vitrine — cabinet conseil
Site corporate — PME industrielle
Landing page — SaaS B2B
E-commerce — boutique artisanale
Les gains de score ne sont que la surface visible. Ce qu'on observe systématiquement derrière ces chiffres, c'est une baisse du taux de rebond mobile (souvent 10 à 20 points), une hausse du temps passé sur le site, et — surtout — davantage de demandes de contact. La corrélation entre performance et conversion n'est pas théorique. Elle est mesurable, projet par projet.
Le cas le plus frappant reste ce cabinet conseil avec un score initial de 31. Trois semaines après la refonte et le déploiement, les demandes de contact avaient augmenté de 40 %. Le contenu n'avait pas changé. Les services non plus. Seule la performance avait évolué.
12.FAQ — Performance Lighthouse
Lead Developer & Architecte performance chez WebFlowr
Thomas est responsable de la qualité technique sur l'ensemble des projets WebFlowr. Il audite des dizaines de sites par an, définit les standards de performance de l'agence et développe les outils internes de mesure et de suivi des Core Web Vitals. Son obsession : livrer des sites qui ne sacrifient jamais la vitesse au profit du design — parce qu'il sait que les deux peuvent coexister.
Quel est le score de votre site ?
WebFlowr analyse gratuitement votre score Lighthouse, identifie les trois optimisations à fort impact et vous explique comment y remédier.
Obtenir mon audit de performance