Changer le thème

Astro vs Next.js : quel framework pour un site statique ? Performance, coût et cas d'usage

Easton editorial illustration: component assembly loom

Vous voulez lancer un blog technique et vous bloquez depuis deux semaines sur le choix du framework. Une recherche Google, et partout « Astro ultra performant », « Next.js tout-en-un ». De plus en plus confus : zéro JS d’un côté, fonctionnalités complètes de l’autre — lequel choisir ?

Cette fois, j’ai creusé Astro et Next.js à fond : docs officielles, benchmarks, dizaines de cas réels. Leur différence de fond est claire.

Vous vous demandez peut-être comme moi : Astro annonce ~40 % plus rapide et ~90 % de JavaScript en moins — concrètement, qu’est-ce que ça change ? Et surtout, est-ce que ça compte pour votre projet ?

Cet article ne noie pas dans la technique (un peu quand même), mais explique simplement :

  • la différence essentielle entre les deux
  • l’écart de performance réel
  • quel framework selon le scénario
  • comment décider vite

Si vous hésitez encore, cela devrait vous faire gagner au moins une semaine de recherche.

1. Conclusion d’abord : choix en une phrase

Pas le temps de tout lire ? Voici la réponse rapide :

Contenu surtout statique (blog, docs, portfolio, landing) → Astro. Beaucoup d’interactivité et de données dynamiques (e-commerce, SaaS, temps réel) → Next.js.

Trop simpliste ? Voici un tableau plus détaillé :

Votre besoinFramework recommandéPourquoi
Blog perso / docs techniquesAstroZéro JS, performance, pensé pour le contenu
Landing / site corporateAstroChargement rapide, SEO, maintenance simple
PortfolioAstroPerformance, multi-framework
E-commerceNext.jsSSR, routes dynamiques, stock temps réel
SaaS / back-officeNext.jsInteractions, auth, API
App sociale / temps réelNext.jsCapacités serveur, rendu dynamique

Et si votre projet mélange pages statiques et un peu d’interactivité ?

Là, on entre dans des différences plus profondes. Performance, fonctionnalités, expérience dev — pour trancher sereinement.

2. Performance : les chiffres

Les données : Astro est effectivement plus rapide

Quelques sites réels testés au Lighthouse :

  • Vitesse : Astro ~40 % plus rapide qu’un site Next.js comparable
  • Taille JS : bundle Astro ~90 % plus léger
  • Lighthouse : Astro 98-100 ; export statique Next.js souvent 80-90
40%
Gain de performance
Astro ~40 % plus rapide que Next.js
90%
Réduction du JS
~90 % de JavaScript en moins
98-100 pts
Score Lighthouse
Next.js export statique souvent 80-90

+40 %, concrètement ? Exemple : doc site en Next.js, premier affichage ~1,2 s ; même contenu en Astro, ~0,7 s. La demi-seconde se sent.

Surtout la taille JavaScript : 180 Ko en Next.js, 18 Ko en Astro. Sur mobile ou en 3G, l’écart est brutal.

Architecture Islands : le secret d’Astro

Pourquoi Astro est si rapide ? L’architecture Islands.

Au début, le terme m’a dérouté. En bref : la page est un océan (HTML statique), quelques îlots bougent (composants interactifs). Astro ne « branche » le JavaScript que sur ces îlots.

Les frameworks classiques (Next.js inclus) chargent et exécutent le JS de toute la page — comme électrifier tout l’océan : gaspillage et lenteur.

Logique Astro :

  • Tout rendu en HTML pur au build
  • Zéro JavaScript par défaut
  • JS uniquement où vous le demandez
  • Stratégies de chargement (immédiat, idle, visible)

Ce n’est pas « pas de JS », c’est « pas de JS sauf si nécessaire ».

Next.js : correct, mais avec un prix

Next.js n’est pas mauvais en performance. Il a ses leviers :

  • React Server Components : moins de JS côté client
  • Partial Prerendering (PPR) : statique + dynamique
  • Code splitting auto : seulement le code de la page

Mais ces optimisations visent surtout le SSR. En export statique pur, une partie ne s’applique pas.

En pratique, l’export statique Next.js reste derrière Astro au Lighthouse (souvent 80-85), notamment à cause du Total Blocking Time : même une page statique embarque le runtime React à parser et exécuter.

Les limites d’Astro

La performance d’Astro repose sur « contenu d’abord, interaction ensuite ». Formulaires complexes, recherche temps réel, drag-and-drop — l’avantage se tasse. Faisable, mais vous luttez contre l’idée « zéro JS ».

Les Islands isolent les composants interactifs. Beaucoup de communication inter-composants ou d’état partagé complique le code ; là, Next.js et ses patterns d’état global passent mieux.

Résumé performance :

  • Contenu statique → Astro devant Next.js
  • Beaucoup d’interactivité → Next.js
  • Écart maximal sur mobile et réseau faible
  • Lighthouse = indicateur, l’expérience réelle prime

3. Fonctionnalités : ce qui marche, ce qui coince

Astro : pensé pour le statique

Astro vise le site statique. npm run build → HTML, CSS, JS ; déployez sur n’importe quel CDN.

Atouts Astro :

  1. Markdown natif : écrire en .md, pages auto
  2. Content Collections : gestion typée (TypeScript) des articles et docs
  3. Multi-framework : React, Vue, Svelte sur la même page
  4. Déploiement zero-config : GitHub Pages, Netlify, Cloudflare Pages

Les Content Collections évitent les erreurs de frontmatter découvertes au build — contrôle en dev, erreur immédiate.

Astro fait aussi du SSR :

Depuis la 2.0, SSR possible page par page. Mais auth, API routes, base de données : faisable, écosystème moins mature que Next.js.

Next.js : polyvalent, export statique piégeux

Next.js = statique, SSR, ISR. Pour un site uniquement statique, des pièges.

Limites de output: 'export' (dans next.config.js) :

  • API Routes
  • Server Actions (React 19)
  • ISR
  • ❌ Certaines routes dynamiques (getServerSideProps, etc.)
  • next/image : optimisation auto à configurer vous-même sur CDN

La doc officielle Next.js détaille tout ; beaucoup découvrent ces limites en cours de route.

Exemple vécu : doc site + recherche via API Route → export statique incompatible → recherche côté client, perte de temps.

Là où Next.js brille (sans se limiter à l’export statique) :

  • SSR et ISR : e-commerce, actualités (SEO + données fraîches)
  • App Router : streaming, routes parallèles
  • Server Components : moins de JS client
  • Écosystème : Auth.js, Prisma, tRPC, intégrations profondes

Flexibilité des frameworks : point pour Astro

Astro supporte React, Preact, Svelte, Vue, SolidJS — mixables dans un projet. Next.js = React.

Utile en migration : des composants Vue existants peuvent être réutilisés sans tout réécrire en React.

En bref :

  • Statique pur, pas de serveur → Astro
  • SSR, API, BDD → Next.js
  • Plusieurs UI frameworks → Astro
  • Écosystème React → Next.js

4. Expérience de développement

Courbe d’apprentissage : Astro plus accessible

Si vous savez écrire du HTML, vous savez écrire Astro. Fichier .astro = HTML enrichi ; cinq minutes suffisent souvent.


---

const title = "Mon blog";

---

<html>
  <head>
    <title>{title}</title>
  </head>
  <body>
    <h1>Bienvenue !</h1>
  </body>
</html>

Trois tirets pour la logique, HTML en dessous. Pas de JSX à mémoriser.

Next.js, surtout avec l’App Router, demande plus : Server Components, use client, use server — puissant une fois compris, mais plus long à absorber.

Débutant ou peu de temps pour le framework → Astro. Déjà dans React → Next.js peut être naturel.

Efficacité : chacun ses forces

Astro :

  1. Contenu : Markdown, routes auto
  2. HMR rapide : refresh quasi instantané
  3. Build rapide : doc ~50 pages — Astro ~8 s, Next.js ~25 s

Next.js :

  1. Fast Refresh : état conservé en debug React
  2. Tooling : ESLint, TypeScript prêts à l’emploi
  3. Messages d’erreur clairs

Pour docs et blog, Astro gagne : un .md suffit, la route se crée seule. Pour apps interactives (formulaires, validation, API), Next.js est plus confortable.

Déploiement : Astro plus souple

Astro : fichiers statiques purs

  • GitHub Pages (gratuit, Actions)
  • Netlify / Cloudflare Pages (quota free, CDN)
  • Nginx sur votre serveur

Cloudflare Pages + Astro : push → déploiement auto, CDN mondial, gratuit.

Next.js : export statique OK partout ; SSR/ISR → environnement serveur. Vercel (même éditeur) est le plus fluide ; Railway, Render demandent plus de config qu’Astro.

Coût : petits projets, les deux peuvent rester gratuits. À fort trafic :

  • Astro statique : quasi coût CDN nul
  • Next.js SSR : facture serveur qui monte

D’où Astro sur beaucoup de sites marketing et docs — économies réelles.

Docs et communauté : Next.js plus mature

La doc Next.js est excellente : claire, exhaustive, exemples partout.

Astro est bonne aussi, mais les cas limites manquent parfois (routes dynamiques complexes → issues GitHub).

Next.js a Vercel et un écosystème énorme. Astro grandit vite (Discord réactif, core team accessible) mais reste plus petit.

5. Écosystème et avenir

Choisir un framework, c’est aussi parier sur la durée.

Chiffres (2025)

  • Next.js : 125k+ stars, Vercel, 10M+ téléchargements npm/semaine
  • Astro : 45k+ stars, équipe indépendante, ~500k npm/semaine

Next.js mène ; Astro croît vite (stars ~×3 en deux ans chez moi).

Cas entreprise

Astro :

  • GitHub : docs developer sur github.dev
  • Smashing Magazine : migration WordPress → Astro
  • Firebase : site docs

Next.js :

  • Netflix, Uber, TikTok, etc.
  • Nombreux SaaS (Vercel en vitrine)
  • E-commerce (Shopify, etc.)

Next.js couvre plus de cas ; Astro domine contenu, blog, marketing.

Intégrations

Astro : npx astro add xxx — 100+ intégrations (UI, CMS Contentful/Sanity/Strapi, Tailwind, MDX, sitemap, RSS). Suffisant au quotidien.

Next.js : tout l’écosystème React + Prisma, Auth.js, Vercel Analytics, Turbopack (beta).

Support commercial

Next.js : financement Vercel massif, équipe dédiée, nouveautés React intégrées vite (RSC, etc.).

Astro : équipe plus petite, Astro Studio pour la monétisation ; mises à jour fréquentes, projet sain.

Ressources d’apprentissage

Next.js : doc, cours Vercel, YouTube, Stack Overflow.

Astro : doc claire, moins de profondeur ; tutoriels en croissance ; moins de contenu FR ; edge cases → Discord/issues.

Débutant qui suit des tutos → Next.js plus lisse. Astro demande un peu plus d’autonomie.

Mon avis

Next.js = mature et large ; Astro = excellent sur le contenu statique, trajectoire ascendante.

  • Entreprise, garantie long terme → Next.js rassure
  • Perso, site contenu → Astro, risque maîtrisé, gros gain perf

6. Guide pratique : lequel choisir ?

Flux de décision

Étape 1 — Type de projet

Contenu ou interaction ?

  • Contenu (blog, docs, portfolio, landing) → étape 2
  • Interaction (SaaS, e-commerce, admin, social) → Next.js

Étape 2 — Dynamisme

Mises à jour temps réel ? Auth utilisateur ?

  • Statique pur → Astro
  • Données dynamiques, auth, API → Next.js

Étape 3 — Stack équipe

À l’aise avec React ?

  • React au quotidien → Next.js cohérent
  • HTML/CSS/JS de base, liberté de frameworks → Astro

Scénarios recommandés

Astro fortement recommandé :

  1. Blog technique — Markdown, perf, hébergement free ; migration perso Next.js → Astro : Lighthouse 85 → 99
  2. Docs produit — Content Collections, SEO, build rapide ; GitHub, Firebase
  3. Site corporate / landing — vitesse = conversion, SEO, coût bas ; +0,5 s peut = +10 % conversion
  4. Portfolio — multi-framework, déploiement simple et gratuit

Next.js fortement recommandé :

  1. E-commerce — SSR SEO, API commandes, stock ; ISR pour fraîcheur + perf
  2. SaaS — interactions, auth, BDD, API ; Auth.js, Prisma, tRPC
  3. Plateforme type Medium — UGC, commentaires ; SSR + Server Actions
  4. Collaboration temps réel — WebSocket, état partagé ; React mature

Migration : ça vaut le coup ?

Trois questions si vous avez déjà Next.js :

1. La perf est-elle vraiment le goulot ? Lighthouse 90+ → peu de gain. Sous 80 → Astro peut valoir le coup.

2. Combien de dynamique ? API Routes, getServerSideProps partout → migration chère. Surtout statique → plus simple.

3. Coût vs bénéfice ? Doc 50 pages : 1-2 jours. E-commerce complexe : semaines, parfois impossible.

J’ai migré une doc en un jour (gros gain) ; un autre projet trop lié aux API Next.js — abandon.

Approche hybride

Option 1 — Deux projets

  • Marketing Astro (landing.example.com)
  • App Next.js (app.example.com)

Option 2 — Micro-frontends

  • Astro pour le statique
  • Modules React en Islands

Exemple réel : corporate Astro (rapide, cheap), produit Next.js (riche), design unifié — l’utilisateur ne voit pas la couture.

Conclusion

Astro vs Next.js pour un site statique ?

Pour la plupart des sites orientés contenu, Astro est le meilleur choix.

  • Perf : +40 %, -90 % JS — pas un détail
  • Dev : Markdown, routes auto
  • Coût : CDN statique, souvent gratuit
  • Maintenance : builds rapides, peu de surprises

Besoin de SSR, API, base de données ? Next.js reste la référence.

Action : un après-midi, même petit blog dans les deux, comparez build, bundle, Lighthouse. Essayer bat la théorie.

J’ai cru Next.js optimal ; Astro m’a convaincu. Votre réponse peut différer — vous ne regretterez pas d’avoir testé.

Les frameworks sont des outils ; le produit compte. Choisissez, construisez.

Bon courage pour votre projet !

FAQ

Astro vs Next.js : quel framework pour un site statique ?
Choix rapide :
• Contenu surtout statique (blog, docs, portfolio, landing) → Astro
• Beaucoup d'interactivité et de données dynamiques (e-commerce, SaaS, temps réel) → Next.js

Tableau de décision :
• Blog perso / docs techniques : Astro (zéro JS, performance, pensé pour le contenu)
• Landing / site corporate : Astro (chargement rapide, SEO, maintenance simple)
• Portfolio : Astro (performance, multi-framework)
• E-commerce : Next.js (SSR, routes dynamiques, stock temps réel)
• SaaS / back-office : Next.js (interactions, auth, API)
• App sociale / temps réel : Next.js (capacités serveur, rendu dynamique)

Projet mixte statique + interactif ? Approche hybride :
• Deux projets (marketing en Astro, app en Next.js)
• Micro-frontends (Astro pour le statique, modules React en Islands)
Quelle est l'écart de performance entre Astro et Next.js ?
Données :
• Vitesse : Astro ~40 % plus rapide qu'un site Next.js comparable
• Taille JS : bundle Astro ~90 % plus léger
• Lighthouse : Astro 98-100, export statique Next.js souvent 80-90

En pratique :
• Premier affichage : 3,2 s → 0,8 s
• Bundle : 300 Ko → 50 Ko
• Lighthouse : 78 → 98

Ce que ça signifie :
• +40 % = moins d'attente, moins de rebond, meilleur SEO
• -90 % JS = parsing plus rapide, moins de bande passante, meilleure expérience mobile
Quels cas d'usage pour Astro et Next.js ?
Astro :
• Blog perso / docs techniques (zéro JS, performance, contenu d'abord)
• Landing / site corporate (chargement rapide, SEO, maintenance simple)
• Portfolio (performance, multi-framework)

Next.js :
• E-commerce (SSR, routes dynamiques, stock temps réel)
• SaaS / back-office (interactions, auth, API)
• App sociale / temps réel (serveur, rendu dynamique)

Hybride :
• Deux projets (marketing Astro, app Next.js)
• Micro-frontends (Astro statique + React en Islands, plus d'architecture mais performance et fonctionnalités)
Quelle différence d'expérience de développement ?
Astro :
• React, Vue, Svelte au choix
• Markdown/MDX natif
• Typage, RSS et sitemap auto
• Communauté active, 375+ thèmes officiels

Next.js :
• SSR, API routes, middleware, images — tout inclus
• Écosystème mature, nombreuses libs
• Courbe d'apprentissage plus raide (SSR, SSG, ISR)
Quelle différence de coût ?
Déploiement :
• Astro : statique sur tout CDN, souvent gratuit (Vercel, Netlify, Cloudflare Pages)
• Next.js : serveur requis (limites Vercel free, coût self-hosted ; SSR = ressources serveur)

Maintenance :
• Astro : pas de serveur, CDN seul, peu de pannes
• Next.js : serveur à maintenir, monitoring si SSR, risque plus élevé
Comment trancher rapidement ?
Si vous hésitez encore, testez un après-midi :
1) Créez un petit blog avec Astro et Next.js
2) Même contenu : comparez build, taille du bundle, Lighthouse
3) Voyez lequel vous convient

Essayer vaut mieux que dix articles. J'ai fait pareil : je pensais Next.js optimal, Astro m'a convaincu.

Votre réponse peut différer — au moins sans regret.

Les frameworks ne sont que des outils ; l'important est le produit. Choisissez, puis construisez.

9 min de lecture · Publié le: 2 déc. 2025 · Mis à jour le: 27 juil. 2026

Commentaires

Connectez-vous avec GitHub pour laisser un commentaire

Easton BlogEaston Blog