React SPAからAstroへ：移行の時期と理由
Reactのシングルページアプリケーションで企業サイトを構築することは、2018年には合理的な設計上の選択でした。Reactは主流のフロントエンドフレームワークで、バンドラーも急速に進化しており、サーバーレンダリングに比べて開発しやすいという利点は大きく感じられました。数年後、そうしたサイトの多くが、実際の事業成果を左右する指標で十分な性能を発揮できていません。Core Web Vitals、検索順位、低速回線の利用者に主要コンテンツが表示されるまでの時間などです。
React SPAからAstroへの移行は、フレームワークを丸ごと置き換える作業ではありません。マーケティングサイトや企業サイトで、どの部分にJavaScriptが必要なのかを見直すことです。すべてのページに完全なクライアントサイド実行環境が必要だという前提が、そもそもこの種のサイトに適切だったのかを問い直します。
企業サイトでReact SPAの性能が伸びない理由
React SPAのパフォーマンス特性は、レンダリングモデルに由来します。ユーザーがページを要求すると、サーバーはJavaScriptバンドルへの参照を含む最小限のHTMLを返します。ブラウザーはバンドルをダウンロードし、JavaScriptを解析・実行してコンポーネントツリーを描画した後、コンテンツを表示します。高速回線でキャッシュがあれば、この処理は気付かないほど短時間で済みます。一方、モバイル回線やキャッシュのない初回アクセスでは、リクエストから主要コンテンツの表示までに秒単位の遅延が生じます。
GoogleのCore Web Vitalsは、この遅延を具体的な指標で示します。Largest Contentful Paintは、画面内の最も大きな要素が描画される時点を測定します。React SPAでヒーローセクションやファーストビューのコンテンツを読み込む場合、通常はJavaScriptの実行後になります。First Contentful Paintは、3つのCore Web Vitals（LCP、INP、CLS）には含まれない補助指標ですが、同様に遅れます。主に静的なマーケティングコンテンツを配信するReact SPAでは、LCPの評価が「改善が必要」や「不良」になることがよくあります。コンテンツが重いからではなく、描画までの処理が必要以上に複雑だからです。
SEOへの影響も、この性能上の問題に重なります。検索エンジンのクローラーはJavaScriptの描画能力を大きく改善しましたが、あらかじめ描画されたHTMLのほうが、依然として確実にインデックスされます。クロールバジェットによって、クローラーが1回の訪問で処理できる量には限りがあります。コンテンツの表示にJavaScriptの実行が必要なページは、HTMLレスポンスにコンテンツが最初から含まれるページとは扱いが異なります。自然検索での露出が見込み顧客の獲得に直結する企業サイトでは、この違いが重要です。
Astroが変えること
Astroの標準出力は静的HTMLです（オンデマンドのサーバーレンダリングも利用できますが、明示的な有効化が必要です）。ページはコンパイル時にファイルとして生成され、ウェブサーバーから直接配信できます。コンテンツの表示にJavaScriptの実行は必要ありません。ホームページを要求すると、すべての本文、構造化データ、メタデータを含む完全なHTML文書が届き、ブラウザーがすぐに描画します。
この設計変更による性能向上は、明確に測定できます。最も大きなコンテンツ要素がJavaScriptの実行後に挿入されるのではなく、最初のHTMLレスポンスに含まれるため、LCPが改善します。FCPも同じ理由で改善します。静的コンテンツには、ブラウザーがサーバーで描画したマークアップにイベントリスナーを再接続するハイドレーション工程が不要なため、操作性も改善します。ハイドレーションが行われるのは、以下で説明するアイランドだけです。企業情報のページによくある、操作要素をまったく持たないページでは、ブラウザーに送るJavaScriptはほぼゼロになります。
ただし、実際の企業サイトの多くは完全に静的ではありません。お問い合わせフォーム、ドロップダウン式のナビゲーションなど、クライアントサイドの動作を必要とする要素があります。そこで役立つのが、Astroのアイランドアーキテクチャです。
アイランドアーキテクチャの実践
Astroのアイランドとは、完全に静的なHTMLに囲まれた、クライアントサイドJavaScriptを必要とするコンポーネントです。ページ全体をハイドレートするためにReactの実行環境をすべて送る代わりに、Astroは必要なコンポーネントにだけJavaScriptを送ります。お問い合わせフォームやドロップダウン式ナビゲーションがアイランドになります。周囲の見出し、本文、画像、フッターは静的HTMLのままです。
これはReact SPAの標準的な前提を逆転させます。React SPAでは「このページのどの部分の描画を省けるか？」と考えます。描画処理のすべてがReactを通るため、通常の答えは「どこも省けない」です。Astroでは「このページのどの部分にJavaScriptが必要か？」と考えます。一般的な企業サイトなら、必要なのは全体のごく一部です。
アイランドにはReact、Preact、Vue、Svelte、Solidなどのフレームワークを使えます。移行のために既存のReactコンポーネントを書き直す必要はありません。Reactで構築した操作要素は、同じコードのままAstroのアイランドとして動作し、周囲のページ構造は静的になります。この互換性があるため、部分的な移行も可能です。操作を担うReactコンポーネントを残しながら、周囲のマーケティングコンテンツではSPA全体の処理負荷を避けられます。
Astroが適している場面
Astroへの移行が特に有効なのは、ページの大部分が静的、または更新頻度が低い場合です。検索からの流入が主要な顧客獲得経路であり、さまざまな回線環境のユーザーに配信し、操作機能がページ全体ではなく特定のコンポーネントに集中していることも判断材料になります。
サービス紹介、会社概要、ブログ、導入事例といった企業情報サイトは、この条件によく当てはまります。コンテンツは一度作成し、何度も配信します。ページの価値は、動的なクライアントサイドの動作ではなく、内容をユーザーと検索エンジンに効率よく届けることにあります。この用途にReact SPAを使うのは過剰な設計であり、性能面の負担も実際に生じます。
一方、アプリケーションとして扱う範囲が複雑な場合、Astroはあまり適していません。認証後に個別のデータを表示する画面、リアルタイム更新、多くの状態を保持するユーザーセッション、ほとんどの要素がクライアントサイドで動く操作密度の高いUIなどです。これらはウェブサイトというよりアプリケーションの特性です。両者の区別は実務では曖昧になりがちですが、移行を判断する際には有効な視点です。
実務的な目安として、1ページに2〜3個を超える操作用コンポーネントがあり、共有状態によって密接に結び付いているなら、Reactのコンポーネントモデルが適したアプリケーションである可能性が高いといえます。ページの中心がコンテンツで、独立した操作要素が1〜2個あるだけなら、アイランドモデルのほうが適しています。
実践的な移行ステップ
React SPAからAstroへの全面移行は、一度に切り替えるのではなく段階的に進めます。各段階の目標は、前の版より改善され、デプロイできる状態にすることです。リスクが積み重なる長期の書き直しを避けます。
第1段階は、現状の確認と分類です。ページの種類ごとに操作要素を調べます。お問い合わせフォーム、ニュースレター登録、JavaScriptで動くナビゲーション、対話的な絞り込み機能はアイランドの候補です。操作を伴わないヒーローセクション、機能一覧、ブログ本文、チーム紹介などは、静的描画への移行対象です。
第2段階は、インフラの準備です。Astroプロジェクトでは、ビルドツールの設定、多言語サイトの場合はi18nルーティング、デプロイ先の決定が必要です。Astroの静的出力は、任意の静的ホスティング基盤に組み込めます。ビルドで生成したファイルは、サーバー上のアプリケーションロジックなしで配信できるため、デプロイとキャッシュ設定を大幅に簡素化できます。
第3段階は、コンテンツの移行です。AstroのコンポーネントモデルはReactに近く、多くのコンポーネントは小さな変更で移植できます。主な違いは、Astroコンポーネント（.astroファイル）が静的描画を担い、Reactコンポーネントは操作用のアイランドに使うことです。この分担は段階的に導入できます。既存のReactコンポーネントを初日からアイランドとして使い、周囲の構造を徐々にAstroテンプレートへ移します。
第4段階は、検証です。移行前後のCore Web Vitalsは、モバイル回線のシミュレーションやキャッシュのない状態など、同等の条件で測定します。同じコンテンツをクライアント描画のReact SPAからAstroの静的出力に移すと、LCPは通常大きく改善します。ただし、改善幅は移行前の状態によって異なるため、推測せずに測定する必要があります。SEOへの影響は、クローラーが更新したページを再インデックスするため、検索データに現れるまで通常数週間かかります。
認識すべきトレードオフ
Astroにもトレードオフがあります。ビルド工程は、クライアントサイドSPAを配信する場合より複雑です。静的出力の場合、コンテンツを変更するには、データベースを更新して即座にページへ反映する代わりに、再ビルドと再デプロイが必要です。編集者が公開後数秒で変更を確認できるCMSの運用に慣れているチームは、コンテンツ更新をビルドのトリガーにする仕組みを組み込むか、短い配信の遅れを受け入れる必要があります。
複雑な操作機能を開発する際は、より明確な設計が必要です。ページ内の複数コンポーネントで共有する状態や、ページ遷移後も保持する状態は、明示的に扱う必要があります。React SPAでは、コンポーネントのコンテキストとクライアントサイドルーティングがこれを自動的に支えます。Astroもビュートランジションをサポートし、標準のブラウザーAPIでアイランド間の状態を共有できますが、単一のReactアプリケーションのコンテキストよりも、意識的に設計する必要があります。
これらは理論上の懸念ではなく、実際に発生するコストです。同時に、移行による価値も確かです。静的描画による性能向上は、わずかな改善にとどまりません。ただし、サーバーレンダリングがあらゆる状況で優れていると決めつけず、利点と負担を正直に評価して移行を判断すべきです。
Astroが示すのは、よりシンプルな標準への回帰です。ブラウザーにHTMLを送り、動作に必要な部分にだけJavaScriptを追加します。内容を明確に伝え、ユーザーへ効率よく届けることが主目的の企業サイトでは、ページを読み込むたびにDOMを再構築する完全なクライアントサイド実行環境よりも適切な出発点です。フレームワークの初期設定に合わせるのではなく、サイトの実際の役割に設計を合わせます。