Qu'est-ce qu'Astro ? Zéro JS, architecture Islands et priorité au contenu en 3 minutes

Il y a peu, j’ai monté un blog technique avec Next.js. Au build, le JavaScript a filé à 500 Ko — pour un site qui affiche surtout des articles en texte et images, pourquoi autant de JS ?

Dans Chrome DevTools, c’était pire : premier affichage ~3 s, alertes « JavaScript inutilisé ». J’ai commencé à me demander si React/Vue pour un site de contenu, ce n’était pas un peu excessif.

Puis Astro. L’idée est simple : la plupart des sites n’ont pas besoin de autant de JavaScript. Ça paraît radical ; en regardant l’architecture, ça tient la route.

À la fin de cet article, vous saurez ce que signifient les trois piliers (priorité au contenu, zéro JS par défaut, architecture Islands), en quoi Astro diffère de Next.js et React, et quand le choisir — ou non. Sans jargon inutile.

Pourquoi les frameworks « lourds » — et 500 Ko de JS pour un site statique ?

Reprenons le fonctionnement d’une SPA classique.

Avec React, le navigateur charge le runtime (~130 Ko), puis votre code, puis l’hydratation : le HTML statique devient des composants interactifs. Logique — sauf que sur une page d’article, 90 % du contenu est du texte et des images sans interaction : pourquoi tout ce JS ?

Une statistique frappante : en moyenne, 60 % des ~500 Ko de JS d’une SPA ne servent à rien. Vous attendez 3 s pour charger du code qui « dort ».

Le décalage est clair : site de contenu vs application très interactive. Un éditeur collaboratif a besoin de beaucoup de JS ; une page produit, vraiment ?

Astro part de là : ne pas envoyer de JS par défaut.

Pilier 1 : priorité au contenu (Content-Focused)

Ce n’est pas « écrivez plus », c’est une philosophie : le cœur du site, c’est montrer du contenu, pas une logique applicative complexe.

Astro distingue :

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

Tester l'MVP →Pub

• Présentation : blog, docs, corporate, fiche produit
• Application : collaboration, back-office, chat, formulaires lourds

Astro vise la première catégorie. Next.js peut faire un blog — comme un tank pour les courses.

Citic Bank a une plateforme de métadonnées niveau finance avec Astro ; migration depuis Next.js : −90 % de JS, +30 % de performance (cas documenté).

"Citic Bank a une plateforme de métadonnées niveau finance avec Astro ; migration depuis Next.js : volume JS −90 %, performances +30 %."

Si le site montre surtout texte, images, vidéo, la plupart des pages restent du HTML statique, rapide et SEO-friendly. Seuls les blocs interactifs (commentaires, recherche) chargent du JS.

L’architecture sert le contenu, pas l’inverse.

Pilier 2 : zéro JavaScript par défaut (Zero JS by Default)

« Zéro JS par défaut » ne veut pas dire « pas de framework moderne », mais aucun JS envoyé au client sauf si vous l’ajoutez.

Next.js (SSG/SSR) envoie souvent React + vos composants pour une hydratation complète — même pour un paragraphe de texte.

Astro : HTML statique pur d’abord. Vous marquez les composants qui ont besoin de JS.

Même site de docs : Next.js ~150 Ko de JS minimum ; Astro parfois 11 Ko, Lighthouse 99.

Un carrousel ? Marquez le composant ; le reste reste statique.

Pas d’interdiction du JS : JS là où c’est utile. Dix modules, neuf statiques → un seul charge du JS.

Pilier 3 : architecture Islands

Imaginez un océan de HTML statique avec quelques îles interactives.

L’océan charge vite sans JS ; chaque île charge son JS sans bloquer les autres.

Le concept vient de Katie Sylor-Miller (Etsy, 2019), popularisé par Jason Miller (Preact). Astro l’a industrialisé tôt.

Techniquement : hydratation partielle — pas tout le virtual DOM, seulement les composants marqués interactifs.

Exemple page d’article :

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

Voir les tarifs →Pub

• Titre et corps (statique)
• Table des matières (statique)
• Commentaires (interactif)
• Boutons de partage (interactif)

Un framework classique hydrate tout ; Astro hydrate commentaires et partage. TTI jusqu’à −300 %.

Directives utiles :

• client:load — dès le chargement (interaction critique)
• client:idle — quand le navigateur est inactif
• client:visible — à l’affichage (carrousel, vidéo)

Chaque île est indépendante : commentaires lents ≠ partage bloqué.

L’architecture Islands, c’est le « chargement à la demande » poussé au maximum.

Trois philosophies de construction web

1. React / Vue / Svelte purs — client lourd

Le navigateur est le runtime ; interactions fluides, gros JS.

• Pour : SaaS, éditeurs, formulaires complexes
• Exemples : Figma, Notion, Google Docs

2. Next.js / Nuxt — plateforme full stack

SSR/SSG + hydratation + API : « plateforme complète ».

• Pour : e-commerce complexe, social, données fréquentes
• Exemples : Netflix, TikTok, Hulu

3. Astro — contenu d’abord

HTML statique par défaut + JS à la demande.

• Pour : blog, docs, corporate, landing, vitrine produit
• Atouts : JS −83 à −90 %, SEO, vitesse

Astro est agnostique : React, Vue, Svelte, même projet mixte. Il ne remplace pas React ; il permet de ne l’utiliser que quand il le faut.

Quand choisir Astro — et quand éviter

✅ Bien adapté :

1. Blog, documentation

   • Texte et images, peu d’interaction (commentaires, recherche)
   • SEO important

2. Site corporate, landing

   • Présentation produit/service
   • Vitesse = conversion
   • Contenu relativement fixe

3. Fiche produit e-commerce

   • Vitrine, pas panier/checkout complet
   • SEO produits

4. Portfolio, page perso

   • Projets et compétences
   • Simple et rapide

❌ Moins adapté :

1. Apps très interactives

   • Collaboration type Figma/Miro
   • Tableaux de bord temps réel
   • Back-office lourd

2. Temps réel

   • Chat, bourse, co-édition live
   • Astro excelle en statique, pas en flux live

3. SPA pure sans SEO

   • React/Vue directement suffisent

Test rapide :

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

Commencer →Pub

1. Contenu ou interactions complexes ?
2. Le site reste-t-il lisible sans JavaScript ?

« Contenu » + « oui » → Astro probablement. « Interaction » + « non » → Next.js ou SPA.

Débutant : courbe d’apprentissage

Syntaxe familière — .astro proche de JSX/Vue. Contenu aussi en .md, .jsx, .vue, mix possible.

Thèmes — Marché Astro : blog, docs, portfolio ; personnalisation rapide.

Dev — Vite + Esbuild, HMR rapide.

Docs — Documentation officielle claire, communauté active.

Pour un blog ou une doc, Astro est souvent le chemin le plus court : peu de config, routing simple.

Conclusion

Les trois piliers :

1. Priorité au contenu — architecture au service du message
2. Zéro JS par défaut — JS seulement où il sert
3. Architecture Islands — îles interactives, hydratation ciblée

Expérience de framework moderne, performances proches du HTML pur : composants, HMR, TypeScript — avec la vitesse du statique.

Blog, docs, corporate, landing : essayez Astro. Ce n’est pas universel ; sur son terrain, c’est très efficace.

Astro n’interdit pas le JS : il évite de vous imposer tout le runtime. Interactif là où il faut — pas partout.

Pour commencer : astro.build et le marché de thèmes. Testez.