Gatsby を Astro に移行 | Social Animal

Gatsby had a good run. It pioneered the React-based static site generator category and introduced thousands of developers to the JAMstack. But it's stalled. Netlify acquired Gatsby in early 2023, development has slowed to a crawl, the plugin ecosystem is deteriorating, and build times on large content sites are still painfully slow.

Astro was built to solve exactly the problems Gatsby created. Zero JavaScript by default, content collections that replace GraphQL complexity, build times that make Gatsby look embarrassingly slow. If you're maintaining a Gatsby content site, migrating to Astro isn't just an upgrade—it's overdue.

Gatsby からの移行を促進する Pain Points

シンプルなデータの GraphQL 複雑性

Gatsby の GraphQL データレイヤーは、ローンチ時には革新的でした。ほとんどのコンテンツサイトにとっては、また大げさすぎることもありました。ブログ記事をリストアップしたいですか？GraphQL クエリを書きます。マークダウンファイルからフロントマターを取得したいですか？GraphQL クエリ。画像を表示したいですか？特別なコンポーネントにラップされた GraphQL クエリ。

50 ページのマーケティングサイトでは、独自のファイルシステムに存在するコンテンツをレンダリングするだけで、数十の GraphQL クエリを保守しています。抽象化により、認知的オーバーヘッドが追加され、それに見合う利益がありません。

スケーリングが悪いビルド時間

Gatsby のビルドパイプラインは、各ページを GraphQL レイヤーで処理し、イメージ変換を実行し、各ルートの完全な React バンドルを生成します。500 ページのコンテンツサイトは、10～15 分でビルドできます。2,000 ページのサイト？インクリメンタルビルドが有効になっていても、30 分以上かかります。

コンテンツの更新はすべて待機を意味します。すべてのタイポ修正は待機を意味します。コンテンツチームはツールに恨みを抱き始めます。

プラグインエコシステムが衰退している

Gatsby の強みはそのプラグインエコシステムでした—gatsby-plugin-image、gatsby-plugin-sharp、gatsby-source-filesystem、gatsby-transformer-remark。これらのプラグインの多くは、1 年以上にわたって意味のある更新がされていません。依存関係の競合が増加します。セキュリティアドバイザリが積み重なります。npm audit を実行すると、47 の脆弱性が表示され、ほとんどが Gatsby 依存関係ツリーの深くにあります。

重い JavaScript バンドル

Gatsby は、インタラクティビティがゼロのページでも、すべてのビジターに React ランタイム全体を配信します。静的な「About Us」ページでも、React、ReactDOM、Gatsby のランタイムがダウンロードされます。Lighthouse スコアが低下し、Core Web Vitals が低下し、接続速度が遅いユーザーが代償を支払います。

Astro が提供するもの

コンテンツコレクションが GraphQL を置き換える

Astro のコンテンツコレクションは、コンテンツサイト用に目的で構築されています。TypeScript でスキーマを定義し、マークダウンファイルをフォルダにドロップし、getCollection('blog') で照会します。GraphQL なし。特別なプラグインなし。Type セーフなフロントマター検証が付属しています。

// 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(),
  }),
});

それで終わり。gatsby-node.js なし、createPages API なし、GraphQL フラグメントなし。データ取得は、それを必要とするコンポーネント内の単一の関数呼び出しです。

デフォルトでゼロ JavaScript

Astro は、明示的にオプトインしない限り、クライアント側の JavaScript をゼロで配信します。50 ページのマーケティングサイトは、ブラウザに純粋な HTML と CSS を送信します。インタラクティビティが必要な場合—コンタクトフォーム、イメージカルーセル、検索ウィジェット—Astro の Islands アーキテクチャを使用して、そのコンポーネントのみをハイドレートします。

その結果：Lighthouse スコアは、最適化トリックを使用しなくても、モバイルで 95～100 です。

1 秒未満のビルド

Astro は Vite 上で実行されます。500 ページのコンテンツサイトは 30 秒未満でビルドされます。2,000 ページのサイトは 2 分未満でビルドされます。開発での Hot module replacement はインスタントです。コンテンツチームは、Gatsby の開発サーバーが GraphQL スキーマを再コンパイルするのを待つのではなく、変更をミリ秒で確認できます。

フレームワーク不知論コンポーネント

既に Gatsby サイトから React コンポーネントをお持ちですか？Astro はビルド時にレンダリングするか、クライアント側でハイドレートします—選択肢はあなた次第です。段階的に Astro コンポーネントに移行したい、または特定の機能に Vue または Svelte を試したいですか？Astro は同じプロジェクトですべてをサポートします。

Gatsby から Astro への移行プロセス

フェーズ 1：監査とアーキテクチャ（第 1 週目）

既存の Gatsby サイトをマッピングすることから始めます—すべてのページテンプレート、すべての GraphQL クエリ、すべてのプラグイン依存関係、すべてのダイナミックルート。gatsby-node.js 構成を文書化し、カスタムソースプラグインを識別し、すべてのサードパーティ統合をカタログ化します。

そこから、Astro アーキテクチャを設計します：コンテンツコレクションスキーマ、レイアウト階層、統合選択、展開ターゲット。

フェーズ 2：コンテンツ移行（第 2 週目）

Gatsby の構造からコンテンツを Astro コンテンツコレクションに変換する自動化移行スクリプトを構築します。フロントマタースキーマが検証および正規化されます。MDX コンポーネントは、それらの Astro 同等物にマップされるか、フレームワーク島としてラップされます。

Gatsby の gatsby-image 使用法は、Astro の組み込み <Image /> コンポーネントに変換されます。これは、レスポンシブイメージ、フォーマット変換、遅延読み込みをネイティブに処理します—プラグインチェーンは不要です。

フェーズ 3：テンプレートとコンポーネント変換（第 2～3 週目）

Gatsby ページテンプレートが Astro レイアウトとページになります。クライアント側の相互作用が必要ない React コンポーネントは Astro コンポーネントになります—より単純で、より高速、ゼロ JS。対話型コンポーネントは React のままで（または書き直され）、部分的なハイドレーションに client: ディレクティブを使用します。

Gatsby プラグインを Astro 統合で置き換えます：

• gatsby-plugin-sitemap → @astrojs/sitemap
• gatsby-plugin-feed → @astrojs/rss を使用したカスタム RSS
• gatsby-plugin-mdx → @astrojs/mdx を介した組み込み MDX サポート
• gatsby-plugin-sharp → 組み込み astro:assets 画像最適化

フェーズ 4：SEO 保存（第 3 週目）

これは移行が生きるか死ぬかの場所です。徹底的な URL 保存戦略を実装します：

• 301 リダイレクト URL 構造の変更がある場合、ホスティングレベルで構成されてゼロレイテンシリダイレクト
• Canonical タグ 既存の URL 構造と一致するすべてのページ
• 構造化データ（JSON-LD）移行され、Google の Rich Results Test に対して検証済み
• メタタグ 正確に保存—タイトルタグ、説明、Open Graph、Twitter Cards
• XML サイトマップ 再生成され、Google Search Console に送信
• 内部リンク監査 移行後の壊れた参照をキャッチする

Google Search Console で 30 日間監視して、インデックスの問題を即座に検出します。

フェーズ 5：テストとローンチ（第 4 週目）

既存の Gatsby サイトに対する完全なビジュアルリグレッションテスト。パフォーマンスベンチマークが並べて比較されます。アクセシビリティ監査。クロスブラウザテスト。ステージング URL にデプロイしてチームがレビューしてから、ダウンタイムなしでカットオーバーします。

Gatsby サイトがサービスワーカーを使用していた場合（gatsby-plugin-offline で一般的）、既存のビジターのブラウザーでキャッシュの無効化を強制する代替サービスワーカーを配置します—ほとんどの移行ガイドが完全にスキップするステップです。

タイムラインと価格

50～200 ページのコンテンツサイトの典型的な Gatsby から Astro への移行は 3～4 週間 実行され、$8,000 から開始されます。カスタムソースプラグイン、複雑な動的ルーティング、または重い CMS 統合を含む大規模なサイトは、5～6 週間が必要な場合があります。

スコープ要因には、ユニークなページテンプレートの数、カスタム Gatsby プラグイン、サードパーティ API 統合、および React コンポーネントを保持するか、すべてをネイティブ Astro に変換するかどうかが含まれます。

結論

Gatsby は死んでいませんが、改善することはありません。Astro はアクティブに開発されており、繁栄するコミュニティを持ち、コンテンツ豊富なウェブサイト向けにゼロから設計されました。移行パスは十分に文書化されており、パフォーマンスの向上は即座であり、開発チームは GraphQL ボイラープレートを排除してくれたことに感謝するでしょう。

停滞しているフレームワークの保守を中止します。速く動いているものに移動します。