Migrer Nuxt vers Astro | Performance Zéro-JS
Votre site Nuxt expédie 200KB de JavaScript que les lecteurs n'utilisent jamais
Why leave Nuxt?
- Ships the full Vue runtime to static blog posts — 150–300KB of JavaScript that never executes because nothing's interactive
- Breaks hot module reload in Nuxt Content — content disappears after code changes, forcing manual page refreshes mid-development
- Triggers phantom TypeScript errors when Vetur and Volar plugins clash in projects using asyncData or useFetch
- Stalls builds past 500 pages — every static route processes through Vue's full rendering pipeline, turning 2-minute builds into 8-minute waits
- Forces vue-router and SPA navigation overhead on sites where users read articles and follow links — complexity without reader benefit
- Hydrates every page by default — no granular control over which components need interactivity and which should stay static HTML
What you gain
- Load content pages in under 500ms — zero client-side JavaScript means instant paint on 3G connections and budget Android devices
- Hydrate only what moves — island architecture activates your contact form or search filter while leaving article text as pure HTML
- Keep your team's Vue skills — @astrojs/vue integration runs existing components without rewriting to React or Svelte
- Catch schema errors before deploy — Content Collections validate frontmatter at build time with full TypeScript inference
- Build 500-page sites in 30 seconds — Astro's static pipeline skips Vue's rendering overhead, turning 8-minute Nuxt builds into sub-minute deploys
- Preserve every ranking signal — we migrate URL structures, redirects, structured data, and meta tags so Google sees continuity, not a relaunch
Pourquoi les sites Nuxt riches en contenu appartiennent à Astro
Nuxt est un framework phénoménal pour construire des applications Vue. Mais si votre site est principalement du contenu — articles de blog, documentation, pages marketing, bases de connaissances — vous expédiez un runtime Vue complet pour rendre ce qui est essentiellement du HTML statique.
Astro a été construit exactement pour cela. Il rend les pages en HTML statique au moment de la compilation et envoie zéro JavaScript côté client par défaut. Quand vous avez besoin d'interactivité, vous optez pour l'architecture en îles. Les pages de contenu se chargent instantanément, les scores Lighthouse atteignent trois chiffres, et votre facture d'hébergement baisse.
Le meilleur ? Vous n'avez pas à abandonner Vue. L'intégration @astrojs/vue d'Astro vous permet d'apporter vos composants Vue existants. Ce n'est pas un divorce de framework — c'est une mise à niveau stratégique.
Les vrais problèmes avec Nuxt pour les sites de contenu
Surcharge JavaScript que vous ne pouvez pas éliminer
Même en mode génération de site statique, Nuxt hydrate l'ensemble de la page avec Vue. Votre article de blog de 2 000 mots est livré avec vue-router, le runtime Vue et des scripts d'hydratation. Sur mobile avec des connexions lentes, votre contenu se cache derrière un mur d'exécution JavaScript.
Nous avons audité des sites de contenu Nuxt expédiant 150-300KB de JavaScript pour des pages sans aucun élément interactif. Ce n'est pas un problème Vue — c'est une inadéquation architecturale.
Particularités du serveur de développement et problèmes HMR
Si vous avez utilisé Nuxt avec le module Content, vous avez probablement rencontré le bug notoire du rechargement de module chaud où le contenu disparaît simplement après les modifications de code. Les conflits de plugin VS Code entre Vetur et Volar génèrent des erreurs TypeScript fantômes. Aucune de ces choses ne sont des obstacles en soi, mais elles s'accumulent en frictions quotidiennes qui ralentissent votre équipe.
Les temps de compilation qui s'adaptent mal
La génération statique de Nuxt exécute chaque page à travers le pipeline de rendu de Vue. Avec 500+ pages, les temps de compilation s'étendent sur des minutes. Avec 2 000+ pages, vous avez un sérieux goulot d'étranglement CI/CD. Le pipeline de compilation d'Astro est plus léger car il n'hydrate pas un framework SPA complet pour chaque page.
Routage surconçu pour les sites simples
Nuxt utilise vue-router sous le capot. Puissant pour les SPA, excessif pour les sites de contenu. Vous obtenez la navigation côté client, les transitions de route et les middlewares — des fonctionnalités qui ajoutent de la complexité sans vrai bénéfice quand les utilisateurs lisent simplement des articles et cliquent sur des pages statiques.
Ce qu'Astro vous donne
Zéro JavaScript par défaut
La philosophie centrale d'Astro : envoyer moins de JavaScript. Chaque composant .astro est rendu en HTML et CSS purs au moment de la compilation. Pas de runtime, pas d'hydratation, pas de taxe de framework. Votre article de blog de 2 000 mots est expédié exactement comme il l'est — HTML et CSS.
Architecture en îles pour l'interactivité sélective
Besoin d'un widget de recherche ? Un graphique interactif ? Un formulaire de commentaires ? Enveloppez-le dans une directive client:visible et Astro hydrate uniquement ce composant quand il entre dans la fenêtre d'affichage. Le reste de la page reste du HTML statique. L'hydratation partielle faite correctement.
---
import SearchBar from '../components/SearchBar.vue';
import ArticleBody from '../components/ArticleBody.astro';
---
<SearchBar client:visible />
<ArticleBody />
La SearchBar charge Vue uniquement quand elle est défilée dans la vue. Le corps de l'article est du HTML pur. Les utilisateurs obtiennent l'interactivité là où elle compte et un chargement rapide partout ailleurs.
Gardez vos composants Vue
Installez @astrojs/vue et vos composants Vue single-file existants fonctionnent dans les pages Astro. Vous pouvez migrer progressivement — convertissez les shells de mise en page et de page en composants .astro tout en gardant les composants Vue interactifs complexes intacts.
C'est beaucoup moins perturbateur qu'une réécriture complète Vue-vers-React. Votre équipe continue de travailler dans Vue pour les îles interactives tout en adoptant le templating d'Astro pour le contenu statique. Personne n'a à apprendre un nouveau modèle de composant à partir de zéro.
Collections de contenu avec sécurité des types
Les Collections de contenu d'Astro vous donnent du Markdown et MDX validés par schéma avec le support complet de TypeScript. Définissez votre schéma de contenu une fois, et chaque champ frontmatter obtient une vérification de type à la compilation. Plus d'erreurs de contenu runtime ne s'échappent en production.
Notre processus de migration
Phase 1 : Audit et architecture (Semaine 1)
Nous analysons l'arborescence des composants de votre site Nuxt et classons chaque composant en trois catégories :
- Composants statiques → Convertir en composants
.astro(zéro JS) - Composants interactifs → Garder comme Vue avec directives
client: - Composants de mise en page → Convertir en mises en page Astro
La plupart des sites de contenu finissent avec 80-90% de composants statiques et une poignée d'îles interactives. Nous auditions également votre structure de contenu et la mappons aux Collections de contenu Astro.
Phase 2 : Construction fondationnelle (Semaines 2-3)
Nous construisons l'échafaudage du projet Astro, installons @astrojs/vue et construisons le système de mise en page principal. Les Collections de contenu reçoivent les schémas appropriés. Votre intégration CMS (si headless) est câblée — Astro fonctionne avec chaque CMS headless via des API standard ou des intégrations dédiées.
Le routage est reconstruit en utilisant le système basé sur les fichiers d'Astro. Les routes dynamiques comme [slug].astro remplacent les pages Nuxt [slug].vue. Si vous utilisez Nuxt Content, nous migrons vos fichiers Markdown directement dans le répertoire de contenu d'Astro.
Phase 3 : Migration des composants (Semaines 3-4)
Les composants Vue statiques sont réécrits en tant que composants .astro. Les composants interactifs restent en tant que fichiers .vue avec les directives client: appropriées. Nous testons chaque île isolément pour confirmer que l'hydratation fonctionne correctement.
Phase 4 : QA, validation SEO et lancement (Semaine 5)
Tests de régression complets sur les appareils et navigateurs. Nous validons chaque URL, chaque redirection et chaque balise meta avant le basculement.
Stratégie de préservation SEO
Migrer un site de contenu sans protéger vos classements de recherche est de la malveillance. Voici comment nous le gérons.
Parité d'URL
Nous mappons chaque URL Nuxt existante à son équivalent Astro. Si votre site Nuxt utilise /blog/my-post, le site Astro sert la même URL. Aucune redirection requise pour les routes correspondantes.
Couverture des redirections
Pour toute URL qui doit changer, nous implémentons des redirections 301 à la périphérie (Vercel, Cloudflare ou config Netlify). Nous générons une carte de redirection complète et la validons avec l'analyse automatique avant le lancement.
Migration des balises Meta
Toutes les configurations vue-meta sont portées à la gestion <head> d'Astro. Les balises Open Graph, les URLs canoniques, les données structurées — tout transfère. Nous exécutons des comparaisons avant/après en utilisant Screaming Frog pour détecter les lacunes.
Performance comme SEO
Les Core Web Vitals de Google impactent directement les classements. Le passage des pages hydratées de Nuxt à la sortie zéro-JS d'Astro réduit généralement le Largest Contentful Paint de 40-60%. Ce n'est pas seulement plus rapide — c'est meilleur pour le SEO.
Plan du site XML et RSS
L'intégration @astrojs/sitemap d'Astro génère les plans du site automatiquement. Si votre site Nuxt servait des flux RSS, nous les reproduisons en utilisant le système de points de terminaison d'Astro.
Calendrier et tarification
Une migration Nuxt-vers-Astro typique pour un site de contenu de 50-200 pages prend 4-6 semaines et commence à 8 000 $. Les sites plus grands avec des fonctionnalités interactives complexes, plusieurs types de contenu ou des intégrations CMS personnalisées évoluent vers 15 000-25 000 $.
Les facteurs qui affectent la portée :
- Nombre de modèles de page uniques
- Complexité des composants Vue interactifs
- Exigences d'intégration CMS
- Points de terminaison API personnalisés ou logique côté serveur
- Exigences d'internationalisation
Chaque projet commence par un audit de migration gratuit où nous évaluons votre site Nuxt, identifions la répartition des composants et fournissons un devis à prix fixe.
Cette migration a du sens quand...
Votre site Nuxt est principalement du contenu. Vous êtes frustré par la surcharge JavaScript sur les pages qui n'en ont pas besoin. Vous voulez des scores Lighthouse supérieurs à 95 sans effort d'optimisation héroïque. Et vous voulez garder votre expertise Vue pertinente plutôt que de recommencer avec React.
Si votre site est une application hautement interactive avec une gestion d'état complexe, Nuxt est probablement toujours le bon appel. Mais si vous publiez du contenu et expédiez un runtime SPA complet pour le faire, Astro est clairement la mise à niveau.
The migration process
Discovery & Audit
We map every page, post, media file, redirect, and plugin. Nothing gets missed.
Architecture Plan
New stack designed for your content structure, SEO requirements, and performance targets.
Staged Migration
Content migrated in batches. Each batch verified before the next begins.
SEO Preservation
301 redirects, canonical tags, sitemap, robots.txt — every ranking signal carried over.
Launch & Monitor
DNS cutover with zero downtime. 30-day monitoring period included.
Nuxt vs Astro
| Metric | Nuxt | Astro |
|---|---|---|
| Lighthouse Mobile | 55-75 | 95-100 |
| TTFB | 0.8-2.0s | <0.3s |
| JS Bundle (Content Page) | 150-300KB | 0-5KB |
| Build Time (500 pages) | 3-8 min | 15-30s |
| Hosting Cost | $20-50/mo | $0-20/mo |
| Framework Lock-in | Vue only | Vue + React + Svelte + any |
Common questions
Puis-je conserver mes composants Vue existants lors de la migration vers Astro ?
Oui. L'intégration officielle `@astrojs/vue` d'Astro vous permet d'utiliser des composants single-file Vue directement dans les pages Astro. Les composants Vue interactifs fonctionnent comme des îles hydratées avec des directives `client:`, tandis que le contenu statique est converti en composants `.astro` zéro-JS. La plupart des équipes conservent 10-20% de leurs composants sous forme d'îles Vue.
Mon site sera-t-il beaucoup plus rapide après la migration de Nuxt vers Astro ?
Les pages de contenu voient généralement les scores de performance Lighthouse passer de 55-75 à 95-100. Le Time to First Byte baisse sous 300ms sur les sites déployés en périphérie. Le plus grand gain est de réduire les 150-300KB de JavaScript que Nuxt expédie pour l'hydratation sur les pages sans interactivité.
Vais-je perdre mes classements de moteur de recherche lors de la migration ?
Non, si c'est bien fait. Nous maintenons la parité d'URL, implémentons des redirections 301 pour toute URL modifiée et migrons toutes les balises meta et données structurées. Les gains de performance des pages zéro-JS tendent à améliorer les scores Core Web Vitals, ce qui montre généralement une influence positive sur les classements quelques semaines après le lancement.
Combien de temps prend une migration Nuxt vers Astro ?
Un site de contenu typique de 50-200 pages prend 4-6 semaines. Le calendrier dépend du nombre de modèles uniques, de la complexité des composants interactifs et des exigences d'intégration CMS. Les sites avec une logique côté serveur importante ou une gestion d'état Vue complexe peuvent prendre 6-8 semaines.
Astro supporte-t-il le rendu côté serveur comme Nuxt ?
Oui. Astro supporte SSG, SSR et le rendu hybride — vous choisissez statique ou rendu serveur par page. Pour les sites de contenu, SSG avec déploiement en périphérie offre la meilleure performance. Les pages dynamiques comme les résultats de recherche peuvent utiliser SSR tandis que les articles de blog restent complètement statiques.
Qu'advient-il de mes fichiers markdown du module Nuxt Content ?
Vos fichiers Markdown et MDX migrent directement dans les Collections de contenu d'Astro. Astro ajoute une validation de schéma sécurisée pour le frontmatter, attrapant les erreurs de contenu au moment de la compilation au lieu de la production. La migration est surtout de déplacer les fichiers et de définir les schémas — votre contenu réel reste inchangé.
Cette migration vaut-elle la peine si mon site Nuxt n'a que 20-30 pages ?
Cela dépend de vos objectifs. Si ces pages sont riches en contenu et que vous voyez de mauvais scores Lighthouse mobiles, les gains de performance sont réels même pour les petits sites. Pour les très petits sites, le coût de migration peut ne pas justifier l'amélioration. Notre audit gratuit vous aide à prendre cette décision avec des données réelles.
Ready to migrate?
Free assessment. We'll audit your current site and give you a clear migration plan — no commitment.
Let's build
something together.
Whether it's a migration, a new build, or an SEO challenge — the Social Animal team would love to hear from you.