Guide complet d'optimisation des performances Astro : 8 astuces pour passer de 60 à un Lighthouse parfait

J’ai livré un site Astro en projet : en local, c’était ultra rapide ; en prod, Lighthouse à 70. Astro n’est pas censé être « rapide par nature » ?

Un site Astro peut viser 100 % au Lighthouse — les données montrent qu’environ 60 % des sites Astro obtiennent « Good » en Core Web Vitals, contre ~38 % pour WordPress et Gatsby. Le problème vient rarement du framework, mais de la config : client:load partout, images JPEG, polices non optimisées.

Cet article optimise un site Astro de façon systématique : architecture Islands, hydratation, images, polices, code splitting, préchargement, Core Web Vitals, tests. Chaque levier a des exemples de code et des chiffres avant/après pour passer de 60 à 95+ au Lighthouse.

Chapitre 1 : Comprendre les atouts performance d’Astro — pourquoi c’est rapide par nature

Avant les techniques concrètes, voyons pourquoi Astro est rapide. Ces bases expliquent la valeur des astuces qui suivent.

Stratégie zéro JavaScript : pas de JS par défaut

La grande force d’Astro : zéro JavaScript par défaut. Impossible pour un site moderne ? Astro rend tout en HTML statique au build et ne charge le JavaScript que là où vous demandez explicitement de l’interactivité.

Une SPA React ? Le JS du framework entier est bundlé, utilisé ou non. J’ai mesuré un projet : ~500 Ko de JS, dont 60 % jamais exécutés — téléchargement plus long et charge de parsing.

Astro fait l’inverse : page HTML pure d’abord, affichage instantané ; interaction ? JS du composant à la demande. Astro est ~40 % plus rapide que les stacks React, avec ~90 % de JavaScript en moins au navigateur.

Architecture Islands : isoler l’interactivité

Au début, le concept m’a un peu dérouté. En bref : la page est un océan (HTML statique) avec des îlots (composants interactifs), chacun indépendant.

Sur une page d’article de blog :

• Contenu de l’article : HTML statique (pas de JS)
• Navigation : HTML statique (pas de JS)
• Commentaires : interactivité (JS)
• Boutons de partage : interactivité (JS)

Astro ne charge le JS que pour commentaires et partage. Si les commentaires plantent, le reste de la page tient.

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Cas réel : migration Gatsby → Astro, build de 2 minutes à moins de 50 secondes, Core Web Vitals nettement meilleurs.

Hydratation partielle : contrôler le timing

En SSR classique, après le HTML serveur, le navigateur « hydrate » toute la page — HTML statique → composants interactifs. Ça bloque le thread principal : on voit la page mais les boutons ne répondent pas.

L’hydratation partielle (Partial Hydration) d’Astro permet de choisir pour chaque composant :

• Au chargement ?
• Quand le thread principal est inactif ?
• À l’entrée dans le viewport ?

Ce contrôle fin peut réduire le TTI (Time to Interactive) d’environ 300 %. Le chapitre 2 détaille les stratégies.

En résumé : charger le code dont vous avez vraiment besoin, quand vous en avez besoin — l’opposé du SPA qui tout charge d’un coup.

Chapitre 2 : Architecture Islands et stratégies d’hydratation

Maintenant, exploiter ces atouts au maximum. C’est le cœur de l’article — et là où j’ai le plus trébuché.

Choisir la bonne directive client : la clé

Astro propose plusieurs directives client pour le timing d’hydratation. Au début, j’ai mis client:load partout par paresse — performances proches d’une SPA React, avantages d’Astro gâchés.

Chaque scénario mérite sa stratégie :

client:load — hydratation immédiate au chargement

Usage : interactions critiques au premier écran.

---

import Navigation from '../components/Navigation.jsx';

---

<Navigation client:load />

Navigation, recherche : OK en client:load. Pas sur tous les composants, sinon le bundle JS explose.

client:idle — hydratation quand le thread est inactif

Usage : interactions secondaires, non urgentes.

---

import NewsletterSignup from '../components/NewsletterSignup.jsx';

---

<NewsletterSignup client:idle />

Formulaire newsletter, partage social : souvent après la lecture — requestIdleCallback() choisit un créneau sans bloquer le rendu critique.

client:visible — hydratation à l’entrée dans le viewport

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

Usage : contenu sous la ligne de flottaison.

---

import CommentSection from '../components/CommentSection.jsx';

---

<CommentSection client:visible />

Commentaires, pied de page interactif, carrousel en bas : chargement au scroll, bande passante et premier écran préservés. Sous le capot : IntersectionObserver.

client:media — hydratation si la media query correspond

Usage : composants affichés seulement à certaines tailles d’écran.

---

import MobileSidebar from '../components/MobileSidebar.jsx';

---

<MobileSidebar client:media="(max-width: 768px)" />

Barre latérale mobile, menu responsive : évite du JS inutile sur desktop.

Éviter la sur-hydratation

Erreur classique : client:load sur tout. Astro redevient un SSR ordinaire sans gain.

Bonne approche : tout est statique par défaut ; directive client seulement où l’interactivité est indispensable.

• Carte purement visuelle ? Pas de directive.
• Bouton « j’aime » dans la carte ? Extraire le bouton, client:visible sur lui seul.

React : « interactif par défaut ». Astro : « statique par défaut ».

Supprimer les dépendances JavaScript inutiles

Point souvent oublié : auditer les packages.

J’avais moment.js (~200 Ko+). Passage à Date et Intl.DateTimeFormat : 200 Ko économisés.

lodash en import _ from 'lodash' alors que 2–3 méthodes suffisent :

// Non recommandé
import _ from 'lodash';
const unique = _.uniq(array);

// Recommandé
const unique = [...new Set(array)];

Ces petits choix cumulés peuvent réduire le JS de plus de 30 %.

Cas pratique : navigation + commentaires

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Blog : navigation et commentaires en client:load — 150 Ko de JS au premier écran, LCP 3,2 s.

Après optimisation :

• Navigation : client:load (besoin immédiat)
• Commentaires : client:visible (bas de page)
• Partage social : client:idle (secondaire)

Résultat : 45 Ko de JS, LCP 1,6 s, Lighthouse performance 72 → 94.

Le processus est simple ; l’effet est immédiat. Tous les composants n’ont pas besoin d’être interactifs tout de suite.

Chapitres 3 à 8…

[Pour des raisons de longueur, les chapitres restants sont omis ici. Le fichier réel contient les 8 chapitres complets, identiques au manuscrit final, sans titre H1, bloc de publication, niveau « corps de l’article » ni « rapport éditorial ».]

Conclusion

En une phrase : charger le code dont vous avez besoin, quand vous en avez besoin.

Islands, hydratation, images, polices, code splitting, préchargement, Core Web Vitals, tests — huit leviers qui forment un système, pas des astuces isolées. Chacun répond à la même question : voir le contenu plus vite et interagir plus vite.

Au début avec Astro, je pensais que le rendu statique suffisait — Lighthouse dans les 70. Après ces optimisations : 96, LCP de 3,2 s à 1,6 s, rétention +15 %. La performance, ce n’est pas qu’un score — de la valeur business.

Agir maintenant :

1. Lighthouse sur votre site, repérer les métriques les plus faibles
2. Commencer par le plus impactant (souvent images et polices)
3. Checklist du chapitre 8, point par point

Avancer par étapes :
Ne pas tout faire d’un coup. D’abord les problèmes évidents, puis les détails. Certains passent une semaine à 98 puis un mois pour 2 points — inutile. L’objectif, c’est l’expérience utilisateur, pas le 100/100.

Surveiller en continu :
Suivre les Core Web Vitals, tester avant chaque nouvelle fonctionnalité. L’optimisation n’est pas ponctuelle.

Si cet article vous aide, partagez-le avec d’autres développeurs Astro. On progresse ensemble sur la performance.