La recette pour un Lighthouse 95+ partout : stack Astro + Tailwind v4

Un Lighthouse à 95 ou plus sur les quatre catégories n’est pas une question de chance ni de réglages obscurs de dernière minute. C’est le résultat d’une stack qui est performante par construction, plus une checklist de quatre postes que je passe systématiquement avant chaque livraison. La recette tient en une stack : Astro pour l’architecture qui n’envoie aucun JavaScript par défaut, Tailwind v4 pour un CSS qui pèse moins de 15 Ko, et trois disciplines de fond sur les images, les polices et les scripts tiers.

Sur les sites que j’ai livrés en 2025 et 2026, le score Lighthouse Performance mobile est à 96 ou au-dessus, et les trois autres catégories — Accessibilité, Bonnes pratiques, SEO — sont à 100. Voici exactement comment j’y arrive, poste par poste, avec les chiffres et les pièges que je rencontre chez mes clients.

Ce que mesurent vraiment les quatre scores

Lighthouse note quatre dimensions, et viser 95+ partout veut dire les traiter toutes, pas seulement la Performance qui aspire toute l’attention.

La catégorie Performance est la seule pondérée par des métriques chiffrées. Selon la documentation de scoring de Chrome, elle agrège cinq mesures : le First Contentful Paint, le Largest Contentful Paint, le Total Blocking Time, le Cumulative Layout Shift et le Speed Index. Le LCP et le TBT pèsent le plus lourd, environ 25% chacun dans la version actuelle. Un site qui charge vite mais bloque le thread principal avec du JavaScript ne dépassera pas 80, même avec un beau LCP.

Les trois autres catégories sont des sommes de tests binaires : une balise existe ou pas, un contraste passe ou pas, une image a un attribut alt ou pas. Le 100 y est atteignable de façon déterministe, contrairement à la Performance qui dépend du réseau et du matériel. C’est pour ça que je traite Accessibilité, Bonnes pratiques et SEO comme un acquis non négociable, et que je concentre l’effort réel sur la Performance.

Un point que je martèle à mes clients : le Lighthouse de votre poste de développeur ment. Il tourne sur votre fibre et votre machine récente. Le score qui compte business, c’est celui des Core Web Vitals mesurées sur le terrain, que Google récupère dans le Chrome User Experience Report et qui alimentent le ranking. Je valide donc toujours via PageSpeed Insights, qui interroge cette base réelle, pas seulement mon Lighthouse local.

La fondation : Astro et le zéro JavaScript par défaut

Le choix d’architecture fait 80% du score avant même la première ligne d’optimisation. Astro repose sur l’architecture en îles : la page est rendue en HTML statique au build, et seul le JavaScript des composants explicitement hydratés est envoyé au navigateur. Par défaut, une page Astro envoie zéro octet de JavaScript, comme le précise la documentation d’Astro sur les îles.

Concrètement, ça change tout pour le Total Blocking Time. Un site React classique livre un bundle qui doit être téléchargé, parsé puis exécuté avant que la page devienne interactive — c’est ce qui plombe le TBT et donc la Performance. Avec Astro, le navigateur reçoit du HTML déjà peint et n’a rien à exécuter pour afficher le contenu.

Quand j’ai besoin d’interactivité — un formulaire de devis, un menu mobile, un carrousel — je l’isole dans une île et je l’hydrate avec la bonne directive. J’utilise client:visible pour qu’un composant ne se charge que lorsqu’il entre dans le viewport, ou client:idle pour différer après le premier rendu. Sur plombiersidf.fr, refait début 2025, seule la carte d’intervention et le formulaire sont hydratés. Le reste de la page est du HTML pur, et le Lighthouse Performance mobile est à 97.

La règle que j’applique : si un composant peut être statique, il reste statique. L’hydratation est un coût, pas un défaut.

Tailwind v4 : un CSS qui ne pèse presque rien

Tailwind CSS v4.0, sorti le 22 janvier 2025, a réécrit son moteur de zéro. Le nouveau moteur, baptisé Oxide, est écrit en partie en Rust et s’appuie sur Lightning CSS pour le parsing, la minification et le préfixage automatique des propriétés. Sur l’annonce officielle, l’équipe Tailwind mesure des builds complets jusqu’à 5 fois plus rapides et des builds incrémentaux plus de 100 fois plus rapides, comptés en microsecondes.

Mais le gain qui m’intéresse pour Lighthouse n’est pas la vitesse de build, c’est la taille du CSS livré. Tailwind ne génère que les classes réellement présentes dans vos fichiers. Pas de feuille de style monolithique, pas de règles mortes héritées d’un thème. Sur mes sites vitrine, la feuille finale tient sous 15 Ko une fois compressée en Brotli. Pour comparaison, le CSS d’un thème WordPress commercial moyen dépasse facilement les 150 Ko, soit dix fois plus.

Tailwind v4 se configure désormais directement en CSS avec la directive @theme, sans le fichier tailwind.config.js d’avant. Pour un projet Astro, l’intégration passe par le plugin Vite officiel, et Lightning CSS gère seul la compatibilité navigateur. Je n’ai plus de PostCSS ni d’autoprefixer à maintenir dans la chaîne.

Le piège à éviter : importer une grosse bibliothèque de composants qui ramène son propre CSS par-dessus Tailwind. À ce moment-là, vous repassez à 100 Ko de CSS et vous perdez le bénéfice. Je préfère écrire mes composants à la main avec les classes Tailwind plutôt que de tirer une dépendance lourde pour gagner trois boutons.

Les images : le poste qui tue le LCP

Dans 9 audits sur 10 que je fais passer, le coupable du mauvais LCP est une image. Le Largest Contentful Paint mesure le temps avant que le plus gros élément visible soit peint, et selon web.dev cet élément est presque toujours une image de héros ou une bannière. Le seuil à tenir est de 2,5 secondes ; au-delà, l’expérience est classée à améliorer.

Astro intègre le composant <Image /> via astro:assets, qui s’appuie sur Sharp pour générer automatiquement des formats modernes — AVIF et WebP — et plusieurs tailles responsives. Trois disciplines suffisent pour verrouiller le LCP.

D’abord, servir l’image au bon format et à la bonne dimension. Une photo de héros de 1600 pixels de large livrée en JPEG de 800 Ko devient un AVIF de 60 à 90 Ko sans perte visible. Sur les sites que je livre, je tiens un poids de page total sous 500 Ko, image de héros comprise.

Ensuite, donner au navigateur les dimensions explicites — width et height — pour qu’il réserve la place avant le chargement. C’est ce qui maintient le Cumulative Layout Shift sous 0,1 et évite le contenu qui saute pendant le rendu.

Enfin, marquer l’image de héros avec loading="eager" et fetchpriority="high", et tout le reste en loading="lazy". Le navigateur télécharge en priorité ce qui est visible immédiatement et diffère le reste. Sur urgenceserrures.fr, ce seul réglage a fait descendre le LCP mobile de 2,8 à 1,1 seconde.

Les polices, le tueur silencieux

Les polices sont le deuxième poste que les gens oublient, et elles cassent à la fois le LCP et le CLS. Une police chargée depuis Google Fonts en ligne ajoute une requête vers un domaine tiers, un temps de connexion, et un risque de texte invisible pendant le chargement.

Je self-host systématiquement les polices, via Fontsource ou en plaçant les fichiers .woff2 directement dans le projet. Trois réglages suffisent. Le font-display: swap affiche d’abord une police système puis bascule, donc le texte est lisible immédiatement. Le préchargement de la police du titre avec <link rel="preload"> évite le flash de texte. Et le sous-ensemble latin seul — au lieu de l’intégralité des glyphes — fait tomber un fichier de police de 120 Ko à 25 Ko environ.

Pour un site français qui n’a besoin que du latin avec accents, embarquer le cyrillique et le grec est du poids mort. Je découpe le sous-ensemble au strict nécessaire, et je limite à deux graisses maximum par police.

Les scripts tiers, et pourquoi je refuse le bandeau cookies

Le troisième poste qui plombe les scores en production, invisible en local, ce sont les scripts tiers : analytics, chat, pixels publicitaires. Chacun bloque le thread principal et alourdit le TBT.

Pour l’analytics, j’utilise Plausible, qui pèse moins de 1 Ko et ne pose aucun cookie. Au-delà de la performance, ce choix a une conséquence réglementaire directe en France. La CNIL indique explicitement qu’un outil de mesure d’audience strictement anonyme et limité à la mesure peut être exempté de consentement, donc dispensé de bandeau cookies. Pas de bandeau, ça veut dire pas de script de gestion du consentement — souvent 30 à 50 Ko de JavaScript bloquant — et pas de friction de conversion. Je gagne sur la performance et sur la conformité RGPD en même temps.

Quand un client tient absolument à un script lourd, je l’isole avec Partytown, qui déporte son exécution dans un web worker pour qu’il ne bloque plus le thread principal. Mais le meilleur script tiers reste celui qu’on n’embarque pas.

La checklist que je passe avant chaque livraison {#summary}

Voici la liste exacte que je coche avant de déclarer un site conforme, dans l’ordre :

1. Architecture Astro, hydratation réservée aux îles strictement interactives, en client:visible ou client:idle.
2. CSS Tailwind v4 sous 15 Ko compressés, sans bibliothèque de composants tierce qui double la feuille.
3. Toutes les images via astro:assets, en AVIF ou WebP, avec dimensions explicites, héros en fetchpriority="high" et le reste en lazy.
4. Poids de page total sous 500 Ko, LCP sous 1,2 seconde, CLS sous 0,1, INP sous 200 ms.
5. Polices self-hostées, sous-ensemble latin, deux graisses maximum, font-display: swap.
6. Analytics Plausible sans cookie, zéro bandeau, aucun script tiers en chargement synchrone.
7. Validation finale sur PageSpeed Insights, pas seulement sur le Lighthouse local.

Cette discipline n’a rien d’héroïque. Elle est répétable parce que la stack fait le gros du travail : Astro élimine le JavaScript superflu, Tailwind v4 élimine le CSS mort, et les trois postes restants sont des habitudes, pas des prouesses. C’est précisément pour ça qu’un freelance solo peut tenir un 95+ que beaucoup d’agences ne tiennent pas : ce n’est pas une question d’effectif, c’est une question de choix techniques faits au départ.

Ce qu’il faut retenir {#takeaways}

• Le score Lighthouse 95+ se gagne par la stack, pas par des réglages de dernière minute : Astro envoie zéro JavaScript par défaut et fait 80% du travail.
• Tailwind v4 et son moteur Oxide via Lightning CSS livrent un CSS sous 15 Ko, contre plus de 150 Ko pour un thème WordPress commercial moyen.
• Les images sont le coupable du mauvais LCP dans 9 audits sur 10 : AVIF ou WebP via astro:assets, dimensions explicites, héros prioritaire.
• Les polices self-hostées en sous-ensemble latin avec font-display swap protègent à la fois le LCP et le CLS.
• Plausible sans cookie supprime le bandeau, le script de consentement et 30 à 50 Ko de JavaScript bloquant, tout en restant conforme à la doctrine CNIL.
• Validez toujours sur le terrain via PageSpeed Insights : le Lighthouse local de votre machine ne reflète pas le réseau réel de vos visiteurs.