Astro vs Next.js : la vérité technique derrière 40 % de performance en plus sur les sites statiques

Pour choisir le framework d’un blog technique, j’ai longtemps hésité : Next.js vient de Vercel et a un écosystème React puissant ; Astro a la réputation d’offrir des « performances explosives » et un « Lighthouse parfait ». Les articles comparatifs se contredisent — Astro plus rapide ici, Next.js plus complet là — et on finit par ne plus savoir.

J’ai passé deux jours à tester les deux avec le même contenu : deux versions de blog, Lighthouse, temps de build, déploiement en production. Résultat : Astro passe de 88 à 100 au Lighthouse, le premier affichage est presque deux fois plus rapide.

Cet article résume mon expérience. Sans hype, avec des chiffres réels — performance, architecture, écosystème et déploiement en quatre dimensions. À la fin, vous saurez lequel choisir.

Duel de performance — qui est vraiment le roi de la vitesse ?

Dans une comparaison Astro Next.js, la performance est incontournable. Pour un blog ou une doc, on veut un chargement rapide et un bon SEO.

Volume JavaScript : 90 % d’écart, ce n’est pas une blague

Commençons par les chiffres les plus parlants. Avec le même contenu, j’ai construit deux blogs (~30 articles, surlignage de code, images) et comparé la taille du bundle JavaScript :

• Next.js export statique : page d’accueil ~85 Ko JS (gzip)
• Astro : page d’accueil ~8 Ko JS (gzip)

L’écart est réel. La promesse officielle d’Astro « 90 % de JavaScript en moins » correspond à mes mesures.

Pourquoi un tel écart ? L’architecture. Next.js, même en SSG, embarque la runtime React, la logique d’hydratation et le routing. Astro rend par défaut du HTML pur — sans JavaScript, sauf si vous ajoutez client:* sur une composante.

En clair : Next.js livre tout le pack React même pour du contenu statique ; Astro ne livre que ce dont vous avez besoin.

Lighthouse : Astro atteint facilement le maximum

La taille du bundle ne suffit pas — l’expérience utilisateur compte. J’ai mesuré les deux sites en production sur Vercel avec Chrome DevTools Lighthouse :

Blog Astro :

• Performance : 100
• Accessibilité : 98
• Bonnes pratiques : 100
• SEO : 100

Blog Next.js (SSG) :

• Performance : 88
• Accessibilité : 98
• Bonnes pratiques : 96
• SEO : 100

L’écart Performance vient surtout du FCP (First Contentful Paint) et du TTI (Time to Interactive). Astro affiche souvent le premier contenu en ~0,5 s, Next.js en 1–1,5 s.

Sous réseau mobile 3G, l’écart se creuse. En simulation Slow 4G, Astro reste à 95+, Next.js tombe autour de 75.

Pour les blogs et docs, l’avantage performance d’Astro est tangible.

Vitesse de build : encore plus visible sur les gros projets

Le temps de build compte aussi. Sur un site de docs de 1 000 pages (Starlight vs Nextra) :

• Astro (Starlight) : ~18 s
• Next.js (Nextra) : ~52 s

Astro est presque 3× plus rapide — proche de la comparaison officielle avec Gatsby.

Pour être juste : Next.js 15 a nettement amélioré le build (avant 80+ s, ~50 s aujourd’hui grâce au parallélisme). L’écart avec Astro reste toutefois notable.

Cas réels : comment les grandes entreprises choisissent

Les chiffres seuls ne suffisent pas — des exemples aident.

Astro, entre autres :

• Documentation développeurs IKEA
• Blog officiel NordVPN
• Docs Firebase
• Centre développeurs Cloudflare

Point commun : contenu d’abord, vitesse extrême, SEO fort.

Next.js, entre autres :

• E-commerce Nike
• Pages marketing Spotify
• Plateforme de contenu Hulu
• Parties de TikTok

Next.js domine quand il faut du dynamique, de l’interaction ou de la personnalisation.

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

Tester l'MVP →Pub

La règle : site purement contenu → Astro ; interaction dynamique → Next.js.

Architecture technique — Islands vs RSC pour le statique

Après les benchmarks, la question : quelle technologie se cache derrière Astro et Next.js ?

Astro Islands : océan de HTML, îlots d’interaction

Le cœur d’Astro est l’architecture Islands. La page est un « océan » de HTML statique ; seuls quelques « îlots » (recherche, commentaires, bouton like) ont besoin de JavaScript.

Par défaut : toute la page en HTML statique. Avec client:*, vous activez des composantes précises :

---

import SearchBox from '../components/SearchBox.jsx'
import StaticHeader from '../components/Header.astro'

---

<StaticHeader /> <!-- HTML pur, pas de JS -->
<SearchBox client:load /> <!-- Îlot : charge du JS -->

Avantages :

1. JavaScript à la demande : seules les parties interactives
2. Hydratation isolée : îlots en parallèle, sans interférence
3. Stratégies flexibles : client:load, client:idle, client:visible

Exemple : surlignage de code en CSS (pas de JS), bascule dark mode avec client:load → page d’accueil ~5 Ko JS seulement.

Chez Next.js, même un surlignage statique passe par la runtime React.

Next.js RSC : Server Components allègent le client

Next.js 15 mise sur les React Server Components (RSC) — idée proche : rendre côté serveur quand c’est possible.

Deux catégories :

1. Server Components (par défaut) : rendus serveur, pas de JS navigateur
2. Client Components ('use client') : interaction, JS envoyé au client

// app/components/Header.jsx
// Par défaut : Server Component, pas de JS
export default function Header() {
  return <header>My Blog</header>
}

// app/components/SearchBox.jsx
'use client' // JS client explicite
import { useState } from 'react'
export default function SearchBox() {
  const [query, setQuery] = useState('')
  // ...
}

Proche des Astro Islands — mais avec des différences :

1. Comportement par défaut

• Astro : zéro JS, îlots manuels
• Next.js : runtime React conservée, moins de code composant

2. Scénarios

• Astro Islands : statique + peu d’interaction
• Next.js RSC : beaucoup de dynamique, data fetching serveur

3. Lien au framework

• Astro : React, Vue, Svelte mélangables
• Next.js : centré React

Sites statiques : qui convient le mieux ?

Pour du contenu purement statique (blog, docs, portfolio), Astro Islands est plus léger. Un blog Markdown pur peut tourner sans aucun JS ; Next.js demande au minimum ~40–50 Ko de runtime.

Pour des mises à jour fréquentes, Next.js ISR brille : CMS, régénération sélective de pages sans rebuild complet.

Astro 4+ propose Server Islands pour le rendu dynamique différé — l’ISR de Next.js reste cependant plus mature.

Recommandation :

• Plus de 90 % statique : Astro
• Mises à jour fréquentes : Next.js + ISR
• Hybride : selon la stack d’équipe, les deux conviennent

Fonctionnalités et écosystème — expérience développeur comparée

Markdown : Astro prêt à l’emploi, Next.js demande du setup

Pour blog ou docs, Astro est nettement plus agréable.

Markdown Astro :

• .md dans src/pages/ → page immédiate
• MDX intégré
• Content Collections pour un CMS typé :

// src/content/config.ts
import { defineCollection, z } from 'astro:content'

const blog = defineCollection({
  schema: z.object({
    title: z.string(),
    date: z.date(),
    tags: z.array(z.string())
  })
})

export const collections = { blog }

Typage TypeScript, RSS, sitemap — peu d’effort.

Markdown Next.js :

• @next/mdx ou next-mdx-remote
• remark/rehype à câbler soi-même
• souvent contentlayer ou équivalent

Next.js fonctionne — Astro mène plus vite les débutants au but.

Compatibilité frameworks : Astro hub multi-framework

Astro autorise React, Vue, Svelte, Solid, Preact dans le même projet :

---

import ReactNav from './ReactNav.jsx'
import VueForm from './VueForm.vue'
import SvelteChart from './SvelteChart.svelte'

---

<ReactNav client:load />
<VueForm client:visible />
<SvelteChart client:idle />

Next.js est centré React — pas un défaut, mais un positionnement différent.

Pour les sites statiques, la flexibilité d’Astro est un vrai atout : réutiliser des composants existants.

Écosystème plugins : masse Next.js, focus Astro

Next.js :

• Énorme écosystème npm/React
• Intégrations Vercel (Analytics, Edge Config, KV)
• communauté très active

Astro :

• 400+ intégrations officielles et communautaires
• Starlight pour la doc
• optimisation d’images, sitemap, RSS officiels

Pour blog/docs, Astro suffit. Pour des apps complexes, React via Next.js l’emporte.

Courbe d’apprentissage

Astro : HTML/CSS/JS suffisent ; syntaxe .astro proche des SFC Vue ; docs claires — opérationnel en ~10 minutes.

Next.js : React requis ; App Router avec Server/Client Components, layouts, data fetching — plus de concepts.

Pour un blog rapide, Astro est souvent plus confortable.

Solutions docs : Starlight vs Nextra

Astro Starlight :

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

Commencer →Pub

• Officiel, intégration profonde
• sidebar, recherche, i18n automatiques
• compatible Lighthouse, thème moderne

Next.js Nextra :

• par Vercel, basé sur Next.js
• très personnalisable, composants React
• un peu plus lent que Starlight, mais solide

Avec Starlight, j’ai mis une doc en ligne en ~2 h, déploiement inclus — très fluide.

Cas d’usage — arbre de décision

Quand choisir Astro ?

Au moins deux critères → Astro :

1. Contenu d’abord, interaction ensuite

• Blog, docs, site corporate, landing
• ~90 %+ de contenu statique
• peu d’interaction (recherche, commentaires, dark mode)

2. Performance et SEO sont des KPI durs

• Lighthouse proche de 100
• Core Web Vitals impactent le ranking
• beaucoup d’utilisateurs mobile / réseau faible

3. Workflow Markdown

• articles en Markdown, images locales
• API de contenu typée
• RSS/sitemap prêts à l’emploi

4. Multi-framework

• React et Vue dans l’équipe
• réutilisation de composants
• pas de lien à un seul framework

5. Démarrage rapide

• peu de théorie framework
• site fonctionnel en minutes
• stack d’équipe hétérogène

Quand choisir Next.js ?

1. Mises à jour dynamiques

• CMS headless (Contentful, Sanity)
• ISR pour régénération planifiée
• contenu généré par les utilisateurs (commentaires, likes)

2. Routes dynamiques complexes

• e-commerce, communauté, beaucoup de data fetching SSR

3. React-first

• équipe experte React
• librairies React spécifiques
• Auth, Analytics, Edge Functions dans la stack Next.js

4. Rendu hybride

• pages statiques et SSR mélangées
• personnalisation selon la connexion
• API Routes comme BFF

5. Écosystème Vercel

• déploiement et intégrations sur une plateforme

Pratique : histoires de migration

Next.js → Astro :

• Blog situ2001 : statique, Lighthouse 88→100, build divisé par deux
• Doc technique (~1 000 pages) : build 80 s→20 s, premier affichage ~40 % plus rapide

Raisons : pas de runtime React lourde, performance, meilleur Markdown.

Next.js reste pertinent :

• plateforme e-learning avec login et progression
• e-commerce avec ISR
• marketing SaaS avec démos dynamiques

Raisons : SSR/dynamique, expertise React, workflow Vercel.

Coût de migration

Faible (1–2 jours) :

• blog Markdown pur
• pas de composants React complexes
• pas d’API spécifiques Next.js

Moyen (1–2 semaines) :

• composants React custom (Astro Islands)
• pipeline images à ajuster
• layout/routing à refaire

Élevé (déconseillé) :

• nombreux Hooks/state
• API Routes, Middleware
• data fetching serveur complexe

Règle : ~90 % statique → migration rentable ; plus de 30 % dynamique → restez sur Next.js.

Trois questions pour trancher

Q1 : À quelle fréquence mettez-vous à jour le contenu ?

• quotidien/hebdomadaire → Next.js (ISR)
• rarement → Astro (performance)

Q2 : Quel niveau d’interactivité ?

• recherche/commentaires → Astro (Islands)
• beaucoup d’interaction utilisateur → Next.js

Q3 : Stack de l’équipe ?

• multi-framework / HTML → Astro
• React-first → Next.js

Vous devriez avoir une direction claire.

Conseils pratiques — prise en main et déploiement

La théorie suffit — voici la mise en œuvre. Quel que soit le framework, cette section aide à démarrer vite.

Démarrage rapide : Hello World en 10 minutes

Astro :

# Créer le projet
npm create astro@latest my-blog

# Choisir le modèle (Blog ou Empty)
cd my-blog
npm install
npm run dev

http://localhost:4321 — éditez src/pages/index.astro, changement immédiat.

Next.js :

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

Obtenir -15 % →Pub

# Créer le projet
npx create-next-app@latest my-blog

# TypeScript, App Router, Tailwind…
cd my-blog
npm run dev

http://localhost:3000, éditez app/page.tsx.

Les deux démarrent vite ; les modèles Astro sont plus orientés blog, Next.js plutôt application.

Starters recommandés

Astro :

• Astro Blog
• AstroPaper
• Starlight

Next.js :

• Next.js Blog Starter
• Nextra
• Contentlayer Blog

Mon favori blog : AstroPaper.

Déploiement comparé

Vercel :

• Astro : zero-config, npm run build
• Next.js : natif, auto-optimisation
• rapide à l’international, un peu plus lent en Chine ; free tier ~100 Go/mois

Netlify :

• les deux simples ; free tier plus généreux, Functions
• builds souvent un peu plus lents que Vercel

Cloudflare Pages :

• les deux supportés, déploiements rapides
• CDN global, bande passante illimitée (free)
• environnement de build parfois instable

GitHub Pages :

• Astro : configuration directe
• Next.js : output: 'export', limitations
• gratuit, souvent lent en Chine, pas de Server Components

Optimisation pour les utilisateurs en Chine

1. CDN : Cloudflare Pages souvent plus rapide que Vercel
2. Polices : locales ou CDN adapté à la Chine plutôt que Google Fonts
3. Commentaires : Giscus plutôt que Disqus
4. Images : OSS/COS plutôt qu’Imgur

Mon blog tourne sur Cloudflare Pages — correct en Chine.

Limites et contournements

Astro :

• ❌ moins adapté aux dashboards/SaaS très interactifs
• ❌ mises à jour temps réel moins flexibles que Next.js
• ✅ statique dans Astro, dynamique en service séparé

Next.js :

• ❌ souvent overkill pour un blog simple
• ❌ App Router plus raide
• ✅ pour du purement statique, envisagez Astro

Checklist performance (général) :

• ☑ WebP, lazy loading
• ☑ font-display: swap
• ☑ scripts tiers différés
• ☑ HTTP/2, Brotli
• ☑ en-têtes Cache-Control adaptés

Ressources d’apprentissage

Astro :

• Documentation officielle
• Tutoriel blog Astro
• Starlight

Next.js :

• Documentation officielle
• Next.js Learn
• Migration App Router

Conclusion

Astro vs Next.js — pas de « meilleur » absolu. Tout dépend de votre scénario :

Ma recommandation :

• Blog perso, docs techniques : Astro
• Site corporate, landing : Astro — la performance est un avantage
• CMS : mises à jour rares → Astro ; fréquentes → Next.js
• E-commerce, apps complexes : Next.js
• Équipe experte React : Next.js

J’utilise Astro car ~95 % de mon blog est statique, le plaisir d’un Lighthouse parfait et un meilleur flux d’écriture Markdown.

Pour un SaaS avec démo et dashboard, je choisirais à nouveau Next.js.

Testez maintenant :

# Astro
npm create astro@latest test-astro
cd test-astro && npm install && npm run dev

# Next.js
npx create-next-app@latest test-nextjs
cd test-nextjs && npm run dev

Lancez Lighthouse dans Chrome DevTools — les chiffres valent mieux que dix articles comparatifs.

En bref : le framework n’est qu’un outil, le contenu compte. Astro ou Next.js — commencer à écrire importe plus que comparer sans fin.

Questions en commentaires — bonne mise en ligne !