Astro vs Next.js en 2026 : lequel choisir pour un site vitrine

Pour un site vitrine, Astro l’emporte dans la quasi-totalité des cas que je traite. La raison n’est pas une préférence stylistique, c’est l’architecture en îles : Astro n’envoie du JavaScript au navigateur que pour les composants explicitement interactifs, alors que Next.js embarque le runtime React dès qu’une page en a besoin, même en s’appuyant sur les React Server Components. Next.js reste le bon choix dès qu’il y a un compte utilisateur, un état applicatif partagé entre plusieurs pages, ou une vraie logique produit derrière l’interface.

Dans ma pratique, cette question revient à chaque cadrage de projet vitrine. J’ai livré vitriersparis.fr et plombiersidf.fr sur Astro, deux sites métier où le contenu change rarement et où la performance mobile pèse directement sur le taux de conversion du formulaire. Aucun des deux n’avait besoin d’un état applicatif complexe, d’un compte utilisateur ni d’appels API en temps réel. C’est précisément le profil de projet où Astro gagne sans discussion.

Le critère qui tranche vraiment

Une seule question détermine le choix avant même de parler de performance ou de coût : votre site a-t-il besoin d’un compte utilisateur, d’un état partagé entre plusieurs pages, ou d’une logique serveur qui dépasse un formulaire de contact ?

Si la réponse est non, ce qui couvre la grande majorité des sites vitrine, des sites métier locaux et des landing pages que je construis chez mes clients, Astro fait le travail avec moins de JavaScript, moins de code à maintenir et un temps de build plus court. Si la réponse est oui, comme un espace client avec historique de commandes, un tableau de bord SaaS ou une application avec authentification complexe, Next.js et son écosystème React sont mieux armés.

Le piège classique que je vois chez des porteurs de projet, c’est de choisir Next.js par réflexe parce que React est la technologie la plus connue sur le marché, alors que le site n’a besoin que d’afficher du contenu statique avec un formulaire de devis. Ce choix ajoute de la complexité de build, de la dette de dépendances et du JavaScript inutile sans aucun bénéfice fonctionnel en retour.

Ce qu’Astro fait mieux pour un site vitrine

L’architecture en îles ne charge du JavaScript que là où c’est nécessaire. Une page Astro entièrement statique, ce qui décrit la majorité des pages d’un site vitrine (accueil, services, à propos, mentions légales), n’envoie aucun JavaScript de framework au navigateur. Seul un composant explicitement marqué comme interactif, un menu mobile ou un formulaire avec validation côté client par exemple, embarque le JavaScript nécessaire à son fonctionnement, et rien d’autre.

Astro 7, sorti le 22 juin 2026, accélère encore l’écart. Le compilateur .astro a été réécrit en Rust, le pipeline Markdown et MDX tourne désormais sur ce même moteur Rust, et le moteur de rendu est passé à une approche en file d’attente plus rapide. Combiné à Vite 8 et son nouveau bundler Rolldown, l’équipe Astro annonce des builds 15 à 61% plus rapides selon ses propres benchmarks. Sur un site de taille moyenne, c’est la différence entre un build de déploiement de 40 secondes et un build de 15 secondes, ce qui compte concrètement quand on itère plusieurs fois par jour en phase de développement.

Astro 6, sorti le 10 mars 2026, a ajouté une Fonts API intégrée, une API Content Security Policy native et le support des Live Content Collections, qui permettent de brancher une source de contenu externe directement dans la couche de contenu unifiée d’Astro. Cette dernière fonctionnalité est utile quand un client veut garder son contenu dans un CMS headless tout en gardant les pages statiques par défaut.

Le coût du tracking analytics reste négligeable. Sur mes livraisons Astro, j’installe Plausible pour l’analytics, annoncé par l’éditeur à moins de 1 Ko de script chargé, contre un budget JavaScript nettement plus élevé pour Google Analytics avec Tag Manager. Sur une page déjà légère par construction, ce choix ne casse pas l’équilibre.

Ce que Next.js fait mieux

Trois cas de figure justifient encore Next.js pour un projet qui ressemble à un site vitrine au départ.

Premier cas : un vrai état applicatif. Dès qu’il faut un compte utilisateur, un panier persistant multi-session, ou des données qui changent en fonction de qui est connecté, l’écosystème Next.js (Server Actions, Cache Components, gestion de session) est plus mature que ce qu’Astro propose nativement. Next.js 16, avec les Instant Navigations et le Partial Prefetching introduits sur la branche 16.3, rapproche l’expérience d’une single-page app tout en gardant le rendu serveur.

Deuxième cas : une équipe déjà outillée en React. Si l’équipe technique du client maîtrise déjà React et Next.js, et que le projet est amené à devenir une vraie application produit plutôt qu’un site marketing, rester sur Next.js dès le départ évite une migration future. Le React Compiler et React 19.2, embarqués dans les versions récentes de Next.js, réduisent une partie du coût de performance historiquement associé à l’hydratation React.

Troisième cas : l’intégration profonde à l’écosystème Vercel. Edge Functions, preview deployments par pull request, observabilité intégrée : si l’infrastructure de l’entreprise est déjà construite autour de Vercel, Next.js reste le choix qui minimise la friction opérationnelle.

Le tableau comparatif que j’utilise en cadrage

Critère	Astro (îles)	Next.js App Router (RSC)
JS envoyé par défaut sur une page statique	0 Ko hors îles hydratées	Runtime React dès qu’un composant client existe
Cas d’usage idéal	Vitrine, site métier local, landing page	App avec compte utilisateur, dashboard, SaaS
Gestion d’état multi-pages	Non native, à ajouter au besoin	Native via Server Actions et Cache Components
Vitesse de build (v7 / v16)	15 à 61% plus rapide qu’Astro 6 selon Astro	Turbopack par défaut depuis la 16
Courbe d’apprentissage	Proche du HTML, faible	Nécessite de maîtriser React et RSC
Terrain d’hébergement le plus naturel	Netlify, Cloudflare Pages, tout host statique	Vercel, avec le meilleur support des features natives

Les deux lignes qui pèsent le plus dans mes échanges avec les clients sont le JS envoyé par défaut et la gestion d’état. Un site vitrine n’a quasiment jamais besoin d’état partagé entre pages, ce qui retire l’argument principal en faveur de Next.js avant même de parler de performance.

L’idée reçue à démonter : le rendu serveur rendrait Next.js plus rapide

C’est l’erreur de raisonnement la plus fréquente que j’entends chez des clients qui ont déjà un avis technique. Le rendu serveur de Next.js accélère le premier affichage par rapport à une single-page app classique, c’est vrai. Mais comparé à une page Astro entièrement statique et pré-générée au build, la différence structurelle reste la même : Next.js doit encore hydrater le JavaScript React côté client pour que la page devienne interactive, même quand le HTML initial arrive vite. Astro, sur une page sans île interactive, n’a tout simplement rien à hydrater.

Le résultat, ce n’est pas que Next.js est lent, c’est qu’il porte un coût d’hydratation structurel qu’Astro n’a pas sur les pages purement statiques. Ce coût est invisible sur une app riche en interactions où il se justifie largement. Sur une page “Nos services” qui ne fait qu’afficher du texte et des images, ce coût n’achète rien.

Combien ça coûte à héberger

Les deux stacks ont un hébergement gratuit ou quasi gratuit pour un site vitrine de PME. Netlify a supprimé la tarification par siège sur son offre Pro le 14 avril 2026, la rendant forfaitaire à 20 dollars par mois pour un nombre illimité de sièges, ce qui simplifie le calcul pour une petite équipe. Vercel, de son côté, facture toujours 20 dollars par siège de développeur et par mois sur son offre Pro, avec un crédit d’usage inclus du même montant.

Pour un site vitrine Astro sans trafic massif, l’offre gratuite de Netlify ou de Cloudflare Pages suffit largement, ce que je constate sur la totalité de mes livraisons Astro en Île-de-France. Pour un projet Next.js avec des fonctions serveur actives en continu, le budget mensuel dépend davantage de l’usage que du nombre de sièges, ce qui mérite d’être anticipé avant de signer un devis.

Comment je tranche concrètement

Trois questions suffisent dans la grande majorité des cadrages que je mène.

Le contenu de vos pages change-t-il en fonction de qui est connecté ? Si oui, Next.js. Si non, Astro fait le travail avec moins de complexité.

Avez-vous une équipe technique déjà investie dans React et Next.js ? Si oui et que le projet est amené à grossir vers une vraie application, rester sur Next.js évite une migration. Sinon, la syntaxe Astro se prend en main en quelques jours, y compris pour un développeur qui n’a jamais touché React.

Votre priorité est-elle la vitesse de chargement mobile et le coût d’hébergement au plus bas ? Astro gagne quasiment toujours sur ces deux critères pour un site vitrine, parce que l’architecture en îles élimine le JavaScript inutile par construction plutôt que par optimisation a posteriori.

Ce qu’il faut retenir

Pour un site vitrine, la décision se résume à une question d’architecture, pas de préférence. Astro n’envoie du JavaScript que pour les composants explicitement interactifs, ce qui lui donne un avantage structurel sur la performance et le coût d’hébergement pour tout site qui affiche essentiellement du contenu statique. Next.js reste le bon choix dès qu’un compte utilisateur, un état applicatif partagé ou une logique produit entre en jeu, terrain sur lequel son écosystème (Server Actions, Cache Components, intégration Vercel) est plus mature que ce qu’Astro propose nativement. Entre les deux, le critère qui tranche n’est jamais la popularité de la technologie, c’est la présence ou non d’un état applicatif à gérer.

Ce qu’il faut retenir

• Le critère de décision est la présence d’un état applicatif ou d’un compte utilisateur, pas la préférence technologique
• Astro n’envoie du JavaScript que pour les îles explicitement hydratées, contre un runtime React systématique dès qu’un composant client existe sur Next.js
• Astro 7 (22 juin 2026) accélère les builds de 15 à 61% grâce à un compilateur réécrit en Rust et à Vite 8 avec Rolldown
• Next.js reste supérieur pour un vrai état applicatif multi-pages, grâce aux Server Actions et Cache Components introduits sur la branche 16.3
• Netlify a supprimé la tarification par siège sur son offre Pro le 14 avril 2026, contre 20 dollars par siège et par mois toujours facturés sur Vercel Pro
• Migrer de Next.js vers Astro est faisable mais plus coûteux que l’inverse, ce qui justifie de choisir la bonne stack dès le cadrage initial