Migrer Gatsby vers Astro | Social Animal

Pourquoi les développeurs quittent Gatsby pour Astro

Gatsby a eu une belle course. Il a pioneered la catégorie des générateurs de sites statiques basés sur React et introduit des milliers de développeurs au JAMstack. Mais il a stagné. Netlify a acquis Gatsby au début de 2023, le développement s'est ralenti considérablement, l'écosystème des plugins se détériore, et les temps de build sur les grands sites de contenu restent encore désespérément lents.

Astro a été construit pour résoudre exactement les problèmes que Gatsby a créés. Zéro JavaScript par défaut, des collections de contenu qui remplacent la complexité de GraphQL, des temps de build qui font paraître Gatsby embarrassamment lent. Si vous maintenez un site de contenu Gatsby, migrer vers Astro n'est pas juste une mise à niveau—c'est long attendu.

Les points douloureux de Gatsby qui conduisent à la migration

Complexité GraphQL pour des données simples

La couche de données GraphQL de Gatsby était innovante au lancement. C'était aussi massif comme overkill pour la plupart des sites de contenu. Vous voulez lister vos articles de blog ? Écrivez une requête GraphQL. Vous voulez extraire le frontmatter d'un fichier markdown ? Requête GraphQL. Vous voulez afficher une image ? Requête GraphQL enveloppée dans un composant spécial.

Pour un site marketing avec 50 pages, vous maintenez des dizaines de requêtes GraphQL juste pour rendre le contenu qui vit dans votre propre système de fichiers. L'abstraction ajoute une surcharge cognitive sans bénéfice proportionnel.

Les temps de build qui se mettent mal à l'échelle

Le pipeline de build de Gatsby traite chaque page à travers sa couche GraphQL, exécute les transformations d'images et génère le bundle React complet pour chaque route. Un site de contenu avec 500 pages peut prendre 10-15 minutes pour construire. Un site avec 2 000 pages ? Vous regardez 30+ minutes, même avec les builds incrémentaux activés.

Chaque mise à jour de contenu signifie attendre. Chaque correction de faute signifie attendre. Votre équipe de contenu commence à détester l'outil.

L'écosystème des plugins se désagrège

La force de Gatsby était son écosystème de plugins—gatsby-plugin-image, gatsby-plugin-sharp, gatsby-source-filesystem, gatsby-transformer-remark. Beaucoup de ces plugins n'ont pas été significativement mis à jour depuis plus d'un an. Les conflits de dépendances se multiplient. Les avis de sécurité s'accumulent. Vous exécutez npm audit et voyez 47 vulnérabilités, la plupart enfouies profondément dans l'arborescence des dépendances Gatsby.

Des bundles JavaScript lourds

Gatsby expédie l'ensemble du runtime React à chaque visiteur, même pour les pages sans aucune interactivité. Une page statique « À propos » télécharge toujours React, ReactDOM et le runtime de Gatsby. Vos scores Lighthouse en souffrent, vos Core Web Vitals s'effondrent, et les utilisateurs sur des connexions plus lentes en paient le prix.

Ce qu'Astro vous donne

Les collections de contenu remplacent GraphQL

Les collections de contenu d'Astro sont conçues spécifiquement pour les sites de contenu. Définissez un schéma en TypeScript, déposez vos fichiers markdown dans un dossier, interrogez-les avec getCollection('blog'). Pas de GraphQL. Pas de plugins spéciaux. Validation de frontmatter type-safe prête à l'emploi.

// 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()),
    image: z.string().optional(),
  }),
});

C'est tout. Pas de gatsby-node.js, pas d'API createPages, pas de fragments GraphQL. Votre récupération de données est un seul appel de fonction dans le composant qui en a besoin.

Zéro JavaScript par défaut

Astro expédie zéro JavaScript côté client à moins que vous ne vous y engagiez explicitement. Un site marketing avec 50 pages envoie du pur HTML et CSS au navigateur. Quand vous avez besoin d'interactivité—un formulaire de contact, un carrousel d'images, un widget de recherche—vous utilisez l'architecture Islands d'Astro pour hydrater uniquement ce composant.

Le résultat : des scores Lighthouse de 95-100 sur mobile sans aucun tour d'optimisation.

Des builds sub-secondes

Astro s'exécute sur Vite. Un site de contenu avec 500 pages se construit en moins de 30 secondes. Un site avec 2 000 pages se construit en moins de 2 minutes. Le remplacement de module à chaud en développement est instantané. Votre équipe de contenu peut prévisualiser les modifications en millisecondes au lieu d'attendre que le serveur develop de Gatsby recompile son schéma GraphQL.

Des composants framework-agnostiques

Vous avez déjà des composants React de votre site Gatsby ? Astro les rend au moment de la construction ou les hydrate côté client—votre choix. Vous voulez migrer graduellement vers les composants Astro, ou essayer Vue ou Svelte pour des fonctionnalités spécifiques ? Astro les supporte tous dans le même projet.

Notre processus de migration Gatsby vers Astro

Phase 1 : Audit et architecture (semaine 1)

Nous commençons par mapper votre site Gatsby existant—chaque modèle de page, chaque requête GraphQL, chaque dépendance de plugin, chaque route dynamique. Nous documentons votre configuration gatsby-node.js, identifions les plugins source personnalisés et cataloguons toutes les intégrations tierces.

À partir de là, nous concevons l'architecture Astro : schémas de collections de contenu, hiérarchie de mise en page, sélections d'intégration et cible de déploiement.

Phase 2 : Migration du contenu (semaine 2)

Nous construisons des scripts de migration automatisés qui transforment votre contenu de la structure de Gatsby aux collections de contenu Astro. Les schémas de frontmatter sont validés et normalisés. Les composants MDX sont mappés à leurs équivalents Astro ou enveloppés en tant qu'îles de framework.

L'utilisation de gatsby-image de Gatsby est convertie au composant <Image /> natif d'Astro, qui gère les images réactives, la conversion de format et le chargement lazy nativement—pas besoin de chaîne de plugins.

Phase 3 : Conversion de modèles et de composants (semaines 2-3)

Les modèles de page Gatsby deviennent des mises en page et des pages Astro. Les composants React qui n'ont pas besoin d'interactivité côté client deviennent des composants Astro—plus simples, plus rapides, zéro JS. Les composants interactifs restent comme React (ou sont réécrits) et utilisent les directives client: pour l'hydratation partielle.

Nous remplaçons les plugins Gatsby par des intégrations Astro :

• gatsby-plugin-sitemap → @astrojs/sitemap
• gatsby-plugin-feed → RSS personnalisé avec @astrojs/rss
• gatsby-plugin-mdx → Support MDX natif via @astrojs/mdx
• gatsby-plugin-sharp → Optimisation d'image natif via astro:assets

Phase 4 : Préservation SEO (semaine 3)

C'est là que vivent ou meurent les migrations. Nous implémentons une stratégie complète de préservation d'URL :

• Redirections 301 pour tout changement de structure d'URL, configurés au niveau de l'hébergement pour des redirections à zéro latence
• Balises canoniques sur chaque page correspondant à votre structure d'URL existante
• Données structurées (JSON-LD) migrées et validées par rapport au test Rich Results de Google
• Balises meta préservées exactement—titres, descriptions, Open Graph, Twitter Cards
• Sitemap XML régénéré et soumis à Google Search Console
• Audit des liens internes pour attraper toutes les références cassées post-migration

Nous monitorons Google Search Console pendant 30 jours post-lancement pour attraper tout problème d'indexation immédiatement.

Phase 5 : Test et lancement (semaine 4)

Test complet de régression visuelle par rapport à votre site Gatsby existant. Benchmarks de performance comparés côte à côte. Audit d'accessibilité. Test cross-browser. Nous déployons vers une URL de staging pour que votre équipe examine, puis basculons avec zéro temps d'arrêt.

Si votre site Gatsby utilisait un service worker (courant avec gatsby-plugin-offline), nous déployons un service worker de remplacement qui force l'invalidation du cache sur les navigateurs des visiteurs existants—une étape que la plupart des guides de migration omettent entièrement.

Timeline et tarification

Une migration Gatsby vers Astro typique pour un site de contenu avec 50-200 pages prend 3-4 semaines et commence à 8 000 $. Les sites plus grands avec des plugins source personnalisés, du routage dynamique complexe ou une intégration CMS lourde peuvent nécessiter 5-6 semaines.

Les facteurs de scope incluent : nombre de modèles de page uniques, plugins Gatsby personnalisés, intégrations d'API tierces, et si vous voulez garder les composants React ou tout convertir en Astro natif.

Le fond du problème

Gatsby n'est pas mort, mais il n'obtient pas mieux. Astro est activement développé, a une communauté florissante, et a été conçu de zéro pour les sites web riches en contenu. Le chemin de migration est bien documenté, les gains de performance sont immédiats, et votre équipe de développement vous remerciera d'avoir éliminé le boilerplate GraphQL.

Arrêtez de maintenir un framework qui s'immobilise. Allez-y avec celui qui se déplace vite.