Pourquoi nous avons choisi Astro pour refaire notre site
Retour d'expérience : migration WordPress → Astro. Performances mesurées, DX, SEO et les pièges de l'i18n.
WordPress a bien servi son temps. Pendant des années, c’était la solution évidente pour un site vitrine : écosystème mature, plugins à foison, hébergement facile. Mais en 2026, quand votre site est censé démontrer votre expertise technique, faire tourner WordPress + Avada + WooCommerce pour afficher 6 pages de texte devient difficile à justifier. Voici ce que la migration nous a appris, chiffres à l’appui.
Le problème avec notre ancien stack
Notre site WordPress affichait des performances mobiles médiocres : un score Lighthouse de 56 sur mobile, mais surtout un LCP catastrophique de plus de 12 secondes (mesuré sous throttling Slow 4G), un TTFB autour de 550 ms et plus de 2,5 Mo de ressources par page. Pour un studio digital qui vend la performance comme argument principal, c’était un problème d’image majeur.
Ce TTFB raconte tout le reste. Chaque page WordPress, même une page « À propos » qui ne change jamais, est reconstruite à la demande : PHP démarre, interroge MySQL, assemble le thème et ses plugins, puis renvoie le HTML. Ce travail serveur se paie à chaque visite. Quand on vend de la performance, livrer une demi-seconde de latence avant le premier octet est intenable.
Mais au-delà du score, le quotidien était pénible :
- Mises à jour WordPress/plugins à gérer régulièrement (sécurité)
- Éditeur visuel Avada : une usine à gaz pour éditer du texte
- Pas de versioning du contenu
- Pas de workflow de développement moderne (pas de staging Git)
Pourquoi pas Next.js ou Nuxt ?
La question s’est posée. Next.js est excellent pour les apps React avec beaucoup d’interactivité — un dashboard, un produit SaaS, un tunnel d’achat dynamique. Mais pour un site principalement statique avec un blog, c’est overkill : on embarque un runtime React côté client pour hydrater des pages qui, dans les faits, ne réagissent à presque rien. Résultat : du JavaScript expédié et exécuté sur le mobile du visiteur pour afficher du texte qui aurait pu rester du HTML pur.
Astro part du postulat inverse, et c’est ce qui a tranché.
L’Islands Architecture, concrètement
Le principe d’Astro tient en une phrase : zéro JavaScript par défaut. Chaque composant .astro est rendu en HTML au moment du build et envoyé tel quel au navigateur. Pas de runtime de framework côté client, pas d’hydratation globale.
Les rares zones réellement interactives — chez nous, les animations GSAP et le formulaire de contact — deviennent des « îlots » (islands) : des fragments isolés qu’on hydrate explicitement avec une directive (client:load, client:visible, client:idle). Le reste de la page reste statique. On ne paie le coût du JavaScript que là où il apporte quelque chose, et client:visible permet même de différer l’hydratation jusqu’à ce que l’îlot entre dans le viewport. C’est exactement le modèle dont avait besoin un site qui est à 95 % du contenu et à 5 % d’interaction.
Content Collections + Zod : un blog typé
L’autre brique décisive, c’est le système de Content Collections. On déclare un schéma de frontmatter avec Zod, et Astro valide chaque fichier Markdown au build :
import { defineCollection, z } from 'astro:content';
const blog = defineCollection({
schema: z.object({
title: z.string(),
description: z.string().max(160),
pubDate: z.date(),
featured: z.boolean().default(false),
}),
});Concrètement : un article sans title, une pubDate mal formatée ou une description trop longue pour le SEO fait échouer le build au lieu de partir en production. Le frontmatter devient typé côté code, l’autocomplétion fonctionne, et on supprime toute une classe d’erreurs qui, sous WordPress, ne se voyait qu’une fois la page publiée.
Ce qu’on a gagné
Avant/après, mesuré avec le même protocole (Lighthouse mobile, throttling Slow 4G, médiane sur 3 runs) :
| Métrique (mobile) | WordPress | Astro |
|---|---|---|
| Performance Lighthouse | 56 | 93 |
| LCP | 12,2 s | 2,42 s |
| TTFB | 557 ms | 32 ms |
| Poids total | 2,56 Mo | 300 Ko |
Soit un score Lighthouse qui passe de 56 à 93, un LCP 5× plus rapide, un TTFB divisé par ~17 et près de 9× moins de poids transféré. Chiffres relevés le 30 mai 2026 sur le build Astro (Lighthouse CLI, page d’accueil) — pas de promesse sans mesure.
Le saut de TTFB de 557 ms à 32 ms n’a rien de magique : c’est le passage d’un rendu PHP/MySQL à la demande à des fichiers HTML pré-générés, servis directement par nginx. Plus de base de données dans la boucle, plus d’interpréteur à démarrer — juste un fichier statique renvoyé depuis le disque. La majeure partie du gain LCP et du poids vient de la même cause : on n’expédie plus le JavaScript et le CSS de plusieurs plugins pour afficher une page.
Les surprises
La bonne surprise : TailwindCSS 4 avec son API CSS-native est une révélation. Plus de fichier de config JavaScript, les tokens design directement dans le CSS avec @theme. L’intégration Astro est native et le build est ultra-rapide.
La moins bonne surprise : l’i18n. Astro propose un routing i18n intégré, mais pour les redirections entre langues avec des slugs différents (/realisations ↔ /portfolio), il faut quand même gérer la logique manuellement. Le routing par défaut suppose des slugs identiques entre locales ; dès qu’on veut des URLs réellement localisées (meilleur pour le SEO et le partage), on doit câbler soi-même la table de correspondance et les balises hreflang. Rien d’insurmontable, mais à anticiper si le multilingue est central pour vous.
La DX en pratique
Le workflow quotidien tient sur quelques points concrets. Les composants .astro mélangent un frontmatter TypeScript et du HTML : les props sont typées, les imports d’assets aussi, et une erreur de type s’affiche dans l’éditeur avant même de lancer le build. Le hot-reload est instantané — on sauvegarde, le navigateur reflète le changement sans rechargement complet. Côté style, Tailwind 4 ne demande aucun fichier de configuration : on déclare ses tokens dans un bloc @theme du CSS et c’est tout. Et grâce aux Content Collections, ajouter un article revient à déposer un fichier Markdown : le schéma le valide, la page se génère, rien à brancher à la main.
Faut-il migrer ?
Si votre site est une app fortement interactive, Next.js ou Nuxt restent les bons outils. Mais si vous avez un site vitrine, un blog ou un site marketing — autrement dit beaucoup de contenu et peu d’interaction — Astro est aujourd’hui le choix le plus rationnel, et nos propres chiffres le confirment.
Vous voulez savoir ce qu’une stack statique ferait gagner à votre site actuel ? Demandez-nous un audit de performance : on mesure votre Lighthouse, votre LCP et votre TTFB, et on vous dit honnêtement si une migration en vaut la peine.