Lighthouse 100/100 — sans concession

100 sur Performance. 100 sur Accessibility. 100 sur Best Practices. 100 sur SEO.

Sur tous les sites qu’on livre, sur mobile et desktop, mesuré sur Vercel ou Infomaniak. Pas de version « test » servie aux outils, pas de hack pour tromper l’audit. Voici comment.

1. Le choix de stack en amont

Lighthouse 100 impose des contraintes invisibles :

• Aucun JS au-dessus de 200 Ko bundlé
• LCP < 2.5 s sur 3G
• CLS < 0.1
• TBT < 200 ms

Avec React + Next.js, c’est faisable mais contraignant. Avec Astro ou Eleventy en mode statique, c’est par défaut. On choisit Astro 95 % du temps : zéro JS au runtime sauf si tu en demandes explicitement (client:load sur un composant).

Le site sur lequel tu lis ces lignes pèse 53 Ko de JS gzippé, et c’est principalement GSAP pour les animations. Sans GSAP, on serait à 0 Ko.

2. Les quatre obstacles courants

a) Les Google Fonts

Charger une font Google directement coûte 200 à 400 ms en moyenne — DNS lookup, CDN race, parse. Trois solutions :

• Self-host la font dans /public/fonts/ (gain : 150 ms minimum)
• Sous-utiliser les variants — un seul poids = un seul fichier
• font-display: swap pour éviter FOIT (texte invisible pendant le chargement)

Sur ce site, on charge Google Fonts en CDN par confort. C’est notre seule concession. Pour un client en prod, on self-host systématiquement.

b) Les images non-optimisées

WebP n’est plus optionnel en 2026. AVIF non plus pour les sites éditoriaux. Notre stack :

• <picture> avec sources WebP + JPEG fallback
• loading="lazy" sauf pour le LCP (généralement le hero)
• width et height toujours présents (pas de CLS)
• fetchpriority="high" sur le LCP image
• Pour les uploads CMS : pipeline d’optimisation au build (Astro Image, Sharp)

Une image de 800 Ko mal compressée peut tuer ton score à elle seule. Une image de 80 Ko optimisée passe inaperçue.

c) Les scripts tiers

Google Analytics 4, Meta Pixel, Intercom, Hotjar… chaque script tiers coûte 50 à 200 ms et impose un origine externe. Solutions :

• Server-side tracking (GA4 via Measurement Protocol) au lieu du client
• Différer les pixels marketing jusqu’au scroll ou idle
• Tag Manager seulement si tu as 3 scripts ou plus — sinon overhead

Un client e-com qui passe son tracking côté serveur récupère 8-15 points de Performance. C’est régulier.

d) Les frameworks lourds

Pas de débat sur celui-là. En 2026 :

• jQuery : 90 Ko que tu remplaces par 5 lignes de vanilla
• Bootstrap : 200 Ko que Tailwind ou shadcn remplacent en 30 Ko
• Une vieille gallery JS : remplacée par CSS scroll-snap natif

L’audit honnête de la stack héritée fait souvent gagner 30 % de poids et 10 points de Lighthouse.

3. Mesurer après la mise en ligne

Lighthouse en local ment. Le profil simulé n’est pas ton utilisateur réel sur 4G dans le métro. La vraie performance se mesure :

• CrUX dataset (Chrome User Experience Report) — données réelles agrégées par Google
• Sentry ou DataDog RUM pour le monitoring continu
• WebPageTest pour la profondeur de diagnostic (waterfall, filmstrip)
• PageSpeed Insights pour la combinaison synthétique + terrain

On installe au minimum CrUX + un monitoring d’erreur (Sentry) sur tous les projets. Le gain de Lighthouse entre la mise en ligne et 3 mois après est souvent de 5 à 10 points — tu corriges des trucs que tu n’avais pas vus.

En résumé

Lighthouse 100/100 n’est pas une coquetterie technique. C’est :

• Du SEO — Google ranking, Core Web Vitals comme signal de classement
• De la conversion — 8 à 12 % par seconde de gain en LCP, mesuré par WPO Stats
• De l’a11y — l’audit Lighthouse Accessibility est la base WCAG
• Du marketing efficace — les ads convertissent mieux sur les sites rapides (Quality Score Google et CPM Meta s’améliorent)

Si on te livre un site avec 78 sur Performance, on t’a livré un site cassé. Et si ton agence te dit que « 90 c’est très bien », elle te ment ou elle ne sait pas faire mieux.

Pour un audit de performance sur ton site existant, écris-nous. Premier diagnostic gratuit en 48 h.