J'ai reconstruit mon blog avec Astro 5 : score Lighthouse de 68 à 100

La semaine dernière, j’ai entièrement refondu le blog Next.js que j’utilisais depuis deux ans et je suis passé à Astro 5. Le déclencheur : un score Lighthouse à 68 — le blog chargeait si lentement qu’un ami m’a dit qu’il « tournait indéfiniment avant d’apparaître ». Après la migration, le temps de build est passé de 2 minutes à 18 secondes, et le score de performance de 68 à 98.
Cet article couvre trois sujets : pourquoi Astro est si rapide, comment l’utiliser pour un blog, et comment configurer le SEO. Si les performances de votre blog vous ont déjà frustré, la suite devrait vous aider.

Pourquoi Astro mérite votre attention

Franchement, Astro ne m’intéressait pas au départ. Trop de frameworks : Next.js, Nuxt, Gatsby — on ne sait plus où donner de la tête. Je me disais : encore un outil à apprendre, est-ce que ça vaut vraiment le temps investi ?

Jusqu’à ce que je tombe sur ces chiffres —

L’enquête State of JavaScript 2024 place Astro en tête sur l’intérêt, la rétention et la satisfaction. Deuxième en adoption, juste derrière Next.js. GitHub Octoverse 2025 va plus loin : Astro serait le troisième langage à la croissance la plus rapide.

Un autre chiffre marquant : 60 % des sites Astro passent l’évaluation Core Web Vitals, contre 38 % pour WordPress et Gatsby. L’écart est net.

Et qui utilise Astro ? La doc GitHub, la doc développeurs Firebase, Smashing Magazine (migré depuis WordPress). En 2025, Google, Reuters et Typst l’adoptent aussi.

Là, j’ai vraiment réfléchi : mon blog, c’est quoi ? Des articles Markdown, de la coloration syntaxique, parfois un composant commentaires. Ai-je besoin de toute la stack full-stack de Next.js ? Pas vraiment.

Ma conclusion : si vous faites surtout du blog, de la doc ou des landing pages, Astro est probablement le meilleur choix actuel. En revanche, pour une app e-commerce ou SaaS très interactive, Next.js reste plus adapté.

Ce n’est pas une question de « meilleur » en absolu, mais de cas d’usage.

Island Architecture — le secret de la vitesse d’Astro

Vous connaissez ce cas : le contenu s’affiche, mais les boutons ne répondent pas ?

Souvent, c’est l’hydratation JavaScript. Les frameworks classiques envoient tout le JS de la page au navigateur, qui « active » progressivement l’interface. Plus la page est complexe, plus l’attente est longue.

Astro fait l’inverse. Il s’appuie sur l’Island Architecture (architecture en îlots).

Comment le voir ? Imaginez la page comme un océan de HTML statique. Seuls les composants vraiment interactifs — compteur, formulaire, zone de commentaires — « émergent » en petites îles indépendantes. Chaque îlot gère son propre JavaScript, sans gêner les autres.

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

Voir les tarifs →Pub

En code, ça ressemble à ceci :

---
// Ce composant ne charge le JS que lorsqu'il devient visible au scroll
---
<Counter client:visible />
// Ce composant reste du HTML statique pur, sans aucun JS
<Header />

Vous voyez client:visible ? C’est une directive Astro : « n’activer ce composant que quand l’utilisateur le voit ». Il existe aussi client:load (activation au chargement) et client:idle (activation quand le navigateur est inactif).

Résultat concret ? Mon FCP est passé de 2,1 s à 0,8 s, le TTI de 4,5 s à 1,2 s. Côté bundle : 280 Ko de JS, il n’en reste plus que 45 Ko.

Soyons justes : si toute votre page est interactive, Astro n’est peut-être pas le meilleur choix. Son avantage, c’est le contenu majoritairement statique. Pour un blog ou une doc, c’est un changement de niveau.

Server Islands — la nouveauté d’Astro 5

Astro 5 ajoute les Server Islands, assez intéressantes.

Avant : page surtout statique, mais un bloc dynamique (avatar, panier) — que faire ? Tout rendre dynamique, ou renoncer à la personnalisation.

L’idée des Server Islands : d’abord un shell HTML statique, puis injection côté serveur des parties dynamiques.

Officiellement : « performance et personnalisation ne s’excluent plus ». En test, c’est effectivement fluide.

Content Layer — une nouvelle façon de gérer le contenu

Au-delà de 100 articles, un problème revient : la gestion du contenu devient le bazar.

L’approche classique : empiler des Markdown dans src/content, organisés par le système de fichiers. Ça va au début ; ensuite, retrouver un fichier ou brancher un CMS devient pénible.

Le Content Layer d’Astro 5 change la donne.

Au cœur, un mécanisme Loader. Vous chargez depuis n’importe où : Markdown local, Strapi, Contentful, Notion, ou une API maison. Les sources sont unifiées, la gestion devient plus claire.

// astro.config.mjs
import { defineCollection, z } from 'astro:content';
const blog = defineCollection({
  loader: glob({ pattern: "**/*.md", base: "./src/content/blog" }),
  schema: z.object({
    title: z.string(),
    pubDate: z.date(),
    tags: z.array(z.string()),
  }),
});

Cette config charge tous les Markdown de ./src/content/blog ; chaque article doit avoir title, pubDate et tags.

Côté perf, Astro annonce jusqu’à 5× plus rapide pour le Markdown, 2× pour le MDX, et 25 à 50 % de mémoire en moins. Sur mon blog, le build est passé de 2 minutes à 18 secondes — probablement grâce à ça.

J’utilise aujourd’hui un glob loader sur du Markdown local. Prochaine étape : Notion, pour séparer rédaction et publication.

View Transitions — des changements de page fluides

Section plus courte, on passe vite.

Astro 5 renomme l’ancien composant ViewTransitions en ClientRouter — même rôle, nom plus précis pour le routage côté client.

---
import { ClientRouter } from 'astro:transitions';
---
<html>
  <head>
    <ClientRouter />
  </head>
  <body>
    <!-- Votre contenu -->
  </body>
</html>

Avec ce composant, les changements de page ont une transition au lieu d’un saut sec. L’expérience s’améliore nettement.

En 2025, l’API View Transitions native est supportée par presque tous les navigateurs modernes ; Firefox était le dernier. ClientRouter dégrade gracieusement sur les navigateurs non compatibles.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Pour partager un état entre pages (lecteur audio qui continue), ClientRouter est le bon choix. Pour une simple animation, les View Transitions CSS natives suffisent souvent.

Configuration SEO en pratique

Partie importante. Beaucoup pensent qu’Astro « va vite, c’est bon » — le SEO compte aussi. Les moteurs regardent la structure et les métadonnées, pas seulement la vitesse.

Ma première config SEO m’a coûté pas mal d’erreurs. Voici ce qui fonctionne.

Configuration du sitemap

Commencez par le sitemap — basique et facile à oublier.

npx astro add sitemap

Puis dans astro.config.mjs, ajoutez l’URL du site :

import { defineConfig } from 'astro/config';
import sitemap from '@astrojs/sitemap';
export default defineConfig({
  site: 'https://yourdomain.com', // N'oubliez pas cette ligne !
  integrations: [sitemap()],
});

La première fois, j’avais oublié site : le sitemap était en chemins relatifs, Google ne le prenait pas. J’ai mis plusieurs jours à comprendre.

Gestion des balises meta

Chaque article doit avoir son title et sa description. Je les centralise dans le frontmatter Markdown :

---
title: "Guide d'optimisation des performances Astro 5"
description: "Island Architecture et Content Layer d'Astro 5 expliqués en profondeur..."
publishDate: 2025-11-20
ogImage: "/images/astro-5-cover.png"
---

Puis dans le layout :

---
const { title, description, ogImage } = Astro.props.frontmatter;
---
<head>
  <title>{title}</title>
  <meta name="description" content={description} />
  <meta property="og:title" content={title} />
  <meta property="og:description" content={description} />
  <meta property="og:image" content={ogImage} />
  <link rel="canonical" href={Astro.url} />
</head>

L’URL canonique évite que le même contenu soit traité comme dupliqué.

Données structurées (JSON-LD)

Souvent ignorées, mais utiles pour le SEO : indiquer qu’il s’agit d’un article, qui est l’auteur, quand c’est publié.

<script type="application/ld+json">
  {JSON.stringify({
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": title,
    "datePublished": publishDate,
    "author": {
      "@type": "Person",
      "name": "Votre nom"
    }
  })}
</script>

Vérifiez avec le Schema.org Validator.

Tendances SEO 2025

Quelques points importants cette année :

1. Les LLM crawllent aussi vos pages. Moteurs et IA s’appuient sur un contenu structuré ; la clarté bat le bourrage de mots-clés.
2. Les liens internes comptent. Au moins 3 par page, sinon l’indexation peut en pâtir.
3. Principe E-E-A-T — expérience, expertise, autorité, fiabilité : ce n’est pas du folklore, c’est un facteur réel chez Google.

Checklist SEO

À cocher après configuration :

• sitemap.xml généré et accessible
• title et description uniques par page
• attribut alt sur toutes les images
• JSON-LD structuré ajouté
• robots.txt correct
• au moins 3 liens internes par page

Optimisation des images — un tueur de perf sous-estimé

Ça paraît simple, mais compresser ne suffit pas.

Astro intègre astro:assets et un composant Image très capable :

---
import { Image } from 'astro:assets';
import myImage from '../assets/hero.png';
---
<Image
  src={myImage}
  alt="Hero image"
  widths={[400, 800, 1200]}
  format="webp"
/>

Ce code :

1. Déduit largeur/hauteur pour limiter le CLS
2. Génère plusieurs tailles, chargées selon le navigateur
3. Convertit en WebP pour un poids plus faible

Point clé : mettez les images dans src, pas dans public. Astro optimise src, pas public. J’avais mis au mauvais endroit — des fichiers énormes.

Astuce : pour une image distante, inferSize récupère les dimensions :

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

<Image
  src="https://example.com/image.jpg"
  alt="Remote image"
  inferSize
/>

Résultat ? Le projet open source AstroEdge : 4,2 Mo → 0,8 Mo (−82 %), score perf 79 → 100.

Astro 5 ajoute aussi le recadrage expérimental et le support SVG — voir la doc officielle.

Migration depuis d’autres frameworks

Depuis Astro 4 ou un autre framework, lecture rapide.

Changements majeurs d’Astro 5 :

1. ViewTransitions → ClientRouter
2. Astro.glob() déprécié → import.meta.glob() ou getCollection()
3. Mode hybrid fusionné dans la sortie static
4. Service d’images : Squoosh → Sharp
5. Protection CSRF activée par défaut

Commande de migration :

npx @astrojs/upgrade

Elle gère la plupart des compatibilités et signale le reste.

Depuis Next.js ou Gatsby, c’est plus lourd — mais Astro accepte les composants React : migrez d’abord les pages, remplacez les composants progressivement.

Pour conclure

L’essentiel :

1. Island Architecture : zéro JS par défaut, perf naturellement en avance
2. Content Layer : contenu unifié, toute source de données
3. SEO : quelques étapes simples, chacune importante
4. Images : gros levier caché, ne pas négliger
5. View Transitions : navigation plus fluide

Vous hésitez sur le framework de votre blog ? Prenez une demi-heure pour le template officiel Astro et mesurez build + Lighthouse.

npm create astro@latest -- --template blog

Template prêt à l’emploi — ajustez la config et publiez.

Ressources utiles :

• Documentation Astro (anglais, la plus complète)
• Astro 中文网 (traduction chinoise)

Prochain article prévu : tutoriel Astro + Tailwind + MDX pour un blog technique — restez connectés si ça vous intéresse.

Quel framework utilise votre blog ? Les perfs vous ont-elles déjà posé problème ? Dites-le en commentaire.