Astro vs Next.js：静的サイトで 40% 高速化する技術的真実

技術ブログのフレームワーク選びで、しばらく悩みました。Next.js は Vercel 製で React エコシステムが強力。Astro はコミュニティで「パフォーマンスが爆発的」「Lighthouse 満点」と評判。ネットの比較記事を読めば読むほど、Astro が速い派と Next.js が機能豊富派に分かれて、ますます迷います。

2 日かけて両方試しました。同じ内容で 2 つのブログを組み、Lighthouse を回し、ビルド速度を比べ、デプロイして実アクセス速度も測定。結果、Astro の Lighthouse スコアは 88 から 100 に跳ね上がり、初回表示もほぼ半分の時間に短縮されました。

この記事は、その比較のまとめです。誇張なし、実データで語ります。パフォーマンス、アーキテクチャ、エコシステム、デプロイの 4 軸から両フレームワークを深掘りします。読み終われば、自分に合う方が見えてくるはずです。

パフォーマンス対決 — 真のスピードキングはどっち？

Astro Next.js 比較で、パフォーマンスは避けて通れません。ブログやドキュメントサイトなら、表示の速さと SEO は生命線です。

JavaScript サイズの差：90% は伊達じゃない

まず最も分かりやすいデータから。同じ内容（約 30 記事、コードハイライトと画像付き）で 2 つのブログを構築し、ビルド後の JavaScript bundle サイズを比較しました。

• Next.js 静的エクスポート：ホームページ JS 約 85KB（gzip 後）
• Astro：ホームページ JS 約 8KB（gzip 後）

差はリアルです。Astro 公式の「JavaScript 90% 削減」は、実測でもほぼ一致しました。

なぜこんなに違う？鍵はアーキテクチャ設計。Next.js は静的エクスポート（SSG）でも、React ランタイム、ハイドレーションロジック、ルーター管理などの基礎コードをバンドルします。Astro はデフォルトでページを純 HTML にレンダリングし、JavaScript を一切送りません — client:* ディレクティブを付けたコンポーネントだけが例外。

噛み砕くと、Next.js は「静的コンテンツを見せたいだけでも React フルセット」を渡す。Astro は「必要な部分だけ」を渡す、という違いです。

Lighthouse スコア：Astro は余裕の満点

bundle サイズだけでは足りません。Chrome DevTools の Lighthouse で本番環境（Vercel デプロイ）を計測しました。

Astro ブログ：

• Performance: 100
• Accessibility: 98
• Best Practices: 100
• SEO: 100

Next.js ブログ（SSG）：

• Performance: 88
• Accessibility: 98
• Best Practices: 96
• SEO: 100

Performance の差は主に FCP（First Contentful Paint）と TTI（Time to Interactive）由来。Astro は通常 0.5 秒以内に初回コンテンツを描画、Next.js は 1〜1.5 秒かかります。

興味深いのはモバイル 3G シミュレーション。Slow 4G 設定で Astro は Performance 95+ を維持、Next.js は 75 前後まで落ちました。

ブログやドキュメントのようなコンテンツサイトでは、Astro のパフォーマンス優位ははっきり体感できます。

ビルド速度：大規模プロジェクトほど差が出る

開発体験でもビルド速度は重要指標。1000 ページのドキュメントサイト（Starlight と Nextra）で計測しました。

• Astro（Starlight）：約 18 秒
• Next.js（Nextra）：約 52 秒

Astro は約 3 倍速。公式の「Gatsby より 3 倍速い」とほぼ一致します。

公平を期すと、Next.js 15 はビルド性能が大きく改善されています。以前は 80 秒超も珍しくなく、並列ビルド最適化で 50 秒前後まで短縮。それでも Astro には及びません。

実例：大手企業はどう選んでいる？

数字だけでは実感しにくい。採用事例を見ると輪郭がはっきりします。

Astro を採用しているサイト：

• IKEA の開発者ドキュメント
• NordVPN の公式ブログ
• Firebase のドキュメント
• Cloudflare の開発者センター

共通点はコンテンツ主体で、読み込み速度と SEO を極限まで追求していること。

Next.js を採用しているサイト：

• Nike の EC プラットフォーム
• Spotify のマーケティングページ
• Hulu のコンテンツプラットフォーム
• TikTok の一部ページ

Next.js の事例は、動的機能、ユーザーインタラクション、パーソナライズが必要なシーンが多い。

選定のヒントはここから見えます。純粋なコンテンツ展示なら Astro、動的インタラクションが主なら Next.js。

技術アーキテクチャ — Islands vs RSC、静的シーンに向くのは？

パフォーマンスデータを見たあと、Astro と Next.js の技術的な裏側が気になるはずです。

Astro Islands：ページは海、インタラクションは島

Astro のコアは Islands アーキテクチャ（アイランドアーキテクチャ）。初めて聞くと戸惑うかもしれませんが、原理はシンプルです。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

Web ページを「海」（静的 HTML の大部分）と、そこに浮かぶ少数の「島」（インタラクティブコンポーネント）に見立てます。検索ボックス、コメント欄、いいねボタンなど、本当に JavaScript が要る部分だけが島。

Astro はデフォルトでページ全体を静的 HTML にレンダリングし、client:* で特定コンポーネントだけ「開島」します。

---
import SearchBox from '../components/SearchBox.jsx'
import StaticHeader from '../components/Header.astro'
---

<StaticHeader /> <!-- 純 HTML、JS なし -->
<SearchBox client:load /> <!-- 島。JS をロード -->

この設計のメリットは 3 つ。

1. JavaScript のオンデマンドロード：インタラクションコンポーネントだけ JS を送信
2. 独立ハイドレーション：各島は隔離され、並行ロード可能
3. 柔軟なハイドレーション戦略：client:load（即時）、client:idle（アイドル時）、client:visible（表示域に入ったら）

具体例。私のブログトップにはコードハイライトとダークモード切り替えボタンがあります。

• コードハイライトは純 CSS（JS 不要）
• ダークモードボタンは client:load（即座に操作したい）
• 結果：ホームページの JS はボタン分の 5KB だけ

Next.js なら、ハイライトが静的でも React ランタイム全体がバンドルされます。

Next.js RSC：Server Components で負荷を軽減

Next.js 15 の答えは React Server Components（RSC）。「サーバーで描画できるものはクライアントに送らない」という発想で、Astro Islands と似ています。

RSC はコンポーネントを 2 種類に分けます。

1. Server Components（デフォルト）：サーバー描画、JS をブラウザに送らない
2. Client Components（'use client' 宣言）：インタラクションが必要、JS をバンドルして送信

// app/components/Header.jsx
// デフォルトは Server Component、JS なし
export default function Header() {
  return <header>My Blog</header>
}

// app/components/SearchBox.jsx
'use client' // クライアント JS が必要と明示
import { useState } from 'react'
export default function SearchBox() {
  const [query, setQuery] = useState('')
  // ...
}

Astro Islands と似ている？確かに。ただし重要な違いがあります。

1. デフォルト挙動

• Astro：デフォルト JS ゼロ、手動で「開島」
• Next.js：React ランタイムは依然送信、コンポーネントコードだけ削減

2. 向くシーン

• Astro Islands：静的主体でたまにインタラクション
• Next.js RSC：動的コンテンツやサーバーデータ取得が多い

3. フレームワーク依存

• Astro：フレームワーク非依存、React / Vue / Svelte を混在可能
• Next.js：React に深く依存

静的シーンではどちらを選ぶ？

純静的コンテンツ（ブログ、ドキュメント、ポートフォリオ）なら、Astro Islands の方が圧倒的に軽量。極端な例：純 Markdown ブログなら Astro は JS ゼロも可能、Next.js は最低 40〜50KB のランタイムが必要。

動的更新が要るなら話は別。Next.js の ISR（インクリメンタル静的再生成）は、CMS 連携で新記事公開後に特定ページだけ再生成でき、サイト全体の再ビルドは不要。Astro も 4.0 以降 Server Islands で動的部分に対応しましたが、ISR ほど成熟しているとは言いにくい。

私の提案：

• 90% 以上が静的：Astro、パフォーマンスメリットが大きい
• 頻繁なコンテンツ更新：Next.js、ISR が柔軟
• 混合シーン（一部静的＋一部動的）：チームの技術スタック次第、どちらも可能

機能とエコシステム — 開発体験と拡張性

アーキテクチャの次は、実際の開発で気になる点。使い心地は？機能は足りる？

Markdown 処理：Astro は即戦力、Next.js は設定が必要

ブログやドキュメントなら Markdown は避けられません。この点で Astro の体験は段違いです。

Astro の Markdown サポート：

• .md を src/pages/ に置くだけでページ化
• MDX 標準対応、Markdown 内にコンポーネントを書ける
• Content Collections API で型安全なコンテンツ管理：

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

export const collections = { blog }

TypeScript の型補完で記事をクエリでき、RSS や Sitemap も自動生成。とても楽です。

Next.js の Markdown 処理：

• @next/mdx や next-mdx-remote のインストールが必要
• remark / rehype プラグインチェーンを自分で設定
• contentlayer などサードパーティに依存

Next.js でも不可能ではありません。ただ追加設定が要り、初心者には Astro の標準装備の方が明らかに快適です。

フレームワーク互換性：Astro の「大統一」

ここは Astro が圧倒的です。

同一プロジェクトで React、Vue、Svelte、Solid、Preact… ほぼすべての主流フレームワークを混在できます。

• ナビゲーションは React（チームが慣れている）
• フォームは Vue（既存コンポーネントがある）
• チャートは Svelte（軽量）

---
import ReactNav from './ReactNav.jsx'
import VueForm from './VueForm.vue'
import SvelteChart from './SvelteChart.svelte'
---

<ReactNav client:load />
<VueForm client:visible />
<SvelteChart client:idle />

Next.js は React に深く依存。他フレームワークは基本無理。欠点というより位置づけの違い — Next.js は React フルセット体験を提供するフレームワークです。

静的サイトフレームワーク選びの観点では、Astro の柔軟性は実利があります。既存コンポーネントを活かせ、全部書き直す必要がありません。

プラグインエコシステム：Next.js は規模、Astro は特化

Next.js のエコシステムは強力：

• npm 上の React ライブラリが数十万規模
• Vercel 統合（Analytics、Edge Config、KV ストレージ）
• コミュニティが活発、ほぼすべての疑問に答えがある

Astro は規模こそ小さいが十分：

• 400+ の公式・コミュニティ統合
• Starlight はドキュメントサイト特化で標準装備
• 画像最適化、Sitemap、RSS など基本機能は公式サポート

個人的には、ブログやドキュメントなら Astro で困ることはほぼない。複雑なアプリなら Next.js の React エコシステムが効いてきます。

開発者体験：学習曲線の比較

Astro の学習曲線：

• HTML / CSS / JS がわかればほぼゼロから
• .astro ファイル構文は Vue SFC に似てシンプル
• ドキュメントが明快、10 分で触れる

Next.js の学習曲線：

• React の理解が前提
• App Router のメンタルモデルが複雑（Server / Client Components、ネストレイアウト、データ取得）
• 設定項目が多く、初心者は混乱しやすい

Next.js は強力ですが複雑。さっとブログを立てたいなら、Astro のシンプルさの方が気持ちよいはずです。

ドキュメントサイト：Starlight vs Nextra

静的サイトの大きなカテゴリがドキュメント。両フレームワークに専用ソリューションがあります。

Astro Starlight：

• 公式製、深い統合
• サイドバー、検索、多言語切り替えを自動生成
• パフォーマンス極限、Lighthouse 満点
• テーマがシンプルでモダン、すぐ使える

Next.js Nextra：

• Vercel 開発、Next.js ベース
• 機能豊富、高度にカスタマイズ可能
• React エコシステムでコンポーネント選択肢が多い
• パフォーマンスは Starlight ほどではないが十分

Starlight で技術ドキュメントを組み、ゼロからデプロイまで 2 時間。かなりスムーズでした。

適用シーン — 選定フロー

技術詳細はここまで。本題に戻ります。結局どちらを選ぶ？

判断フローを整理しました。自分の要件と照らし合わせてください。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

いつ Astro を選ぶ？

以下に 2 つ以上当てはまるなら、Astro を強く推奨します。

1. コンテンツが主役、インタラクションは脇

• 個人ブログ、技術ドキュメント、企業公式サイト、マーケティング LP
• ページの 90% 以上が静的コンテンツ
• インタラクションは検索ボックス、コメント欄、ダークモード切り替え程度

2. パフォーマンスと SEO が必須

• Google Lighthouse をほぼ満点に近づけたい
• Core Web Vitals がランキングに直結
• モバイル弱電波環境からのアクセスが多い

3. Markdown コンテンツ管理

• 記事は Markdown、画像はローカル保管
• Content Collections のような型安全 API が欲しい
• RSS、Sitemap を標準機能で生成したい

4. 多フレームワーク混在

• チームが React と Vue を併用
• 各フレームワークの既存コンポーネントを再利用したい
• 単一フレームワークに縛られたくない

5. すぐ立ち上げたい

• 複雑な概念を覚えたくない
• 10 分で動くサイトが欲しい
• メンバーの技術スタックがバラバラ

いつ Next.js を選ぶ？

次のような要件なら Next.js が向いています。

1. 動的コンテンツ更新

• Headless CMS（Contentful、Sanity）連携
• ISR で定時またはオンデマンド再生成
• UGC（コメント、いいね、ブックマーク）

2. 複雑な動的ルーティング

• EC（商品詳細、カート、決済）
• コミュニティ（ユーザープロフィール、投稿、返信）
• 大量のサーバーデータ取得

3. React との深い統合

• チームが React を本格運用
• React エコシステムの特定ライブラリに依存
• Auth、Analytics、Edge Functions など Next.js フルセットが必要

4. ハイブリッドレンダリング

• 一部ページは静的、一部は SSR
• ログイン状態に応じたパーソナライズ
• API Routes で BFF 層

5. Vercel エコシステム

• すでに Vercel を利用
• Vercel 統合サービスが必要
• ワンクリックデプロイ＋自動最適化

実例：彼らはどう選んだ？

実際の移行ストーリーを共有します。

Next.js から Astro へ：

• situ2001 のブログ：純静的コンテンツ、移行後 Lighthouse 88→100、ビルド時間半減
• 某技術ドキュメント：1000+ ページ、ビルド 80 秒→20 秒、初回表示 40% 改善

移行理由：

1. React の重量級ランタイムが不要
2. 極限パフォーマンスを追求
3. Markdown 処理体験がよい

Next.js を継続したシーン：

• 某オンライン教育：ログイン、進捗追跡、動的レコメンド
• EC：商品データの頻繁更新、ISR で定時再生成
• SaaS マーケティング：静的紹介ページ＋動的 Demo

選択理由：

1. SSR と動的機能が必要
2. チームに React 蓄積がある
3. Vercel 一体デプロイが便利

移行コストの見積もり

Next.js から Astro へ切り替えるコストは？

低コスト（1〜2 日）：

• 純 Markdown ブログ
• 複雑な React コンポーネントなし
• Next.js 固有 API 非依存

中コスト（1〜2 週間）：

• カスタム React コンポーネントあり（Astro Islands でラップして再利用可能）
• 画像最適化の調整
• レイアウトとルーティングの書き直し

高コスト（移行非推奨）：

• React Hooks と状態管理を大量使用
• Next.js の API Routes、Middleware に依存
• 複雑なサーバーデータ取得

サイトの 90% が静的なら移行メリットは大きい。動的機能が 30% を超えるなら、移行は見送りを。

判断チェックリスト：3 つの問い

まだ迷う？この 3 つに答えてください。

Q1: コンテンツはどのくらいの頻度で更新する？

• 毎日 / 毎週 → Next.js（ISR が便利）
• 数ヶ月に 1 回 → Astro（パフォーマンス優先）

Q2: インタラクション機能はどのくらいある？

• コメント / 検索程度 → Astro（Islands で十分）
• 大量のユーザーインタラクション → Next.js（React エコシステム）

Q3: チームの技術スタックは？

• 複数フレームワーク / 純 HTML → Astro（柔軟）
• React 中心 → Next.js（シームレス統合）

答えが出れば、方向性は見えているはずです。

実践ガイド — 立ち上げとデプロイ

理論はここまで。実際に触れる内容を。

クイックスタート：10 分 Hello World

Astro クイックスタート：

# プロジェクト作成
npm create astro@latest my-blog

# テンプレート選択（Blog または Empty 推奨）
cd my-blog
npm install
npm run dev

http://localhost:4321 を開けば動くサイトが見えます。src/pages/index.astro を編集して保存すると即反映。

Next.js クイックスタート：

# プロジェクト作成
npx create-next-app@latest my-blog

# プロンプトに従って選択（TypeScript、App Router、Tailwind...）
cd my-blog
npm run dev

http://localhost:3000 を開き、app/page.tsx を編集して変化を確認。

どちらも初期化は速い。Astro のデフォルトテンプレートはブログ向き、Next.js はアプリ開発向き。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

おすすめ Starter テンプレート

Astro：

• Astro Blog：公式ブログテンプレート、シンプルで実用的
• AstroPaper：検索、タグ、RSS 付きの高機能ブログテーマ
• Starlight：ドキュメントサイト専用、すぐ使える

Next.js：

• Next.js Blog Starter：公式ブログ例
• Nextra：ドキュメントサイト
• Contentlayer Blog：Contentlayer 統合ブログ

個人的には AstroPaper を推奨。機能、性能、見た目のバランスがよい。

デプロイ方法の比較

フレームワークを決めたらデプロイ。どちらも体験は良好ですが、特徴が異なります。

Vercel（推奨）：

• Astro：ゼロ設定、自動認識、ビルドコマンド npm run build
• Next.js：ネイティブサポート、ワンクリックデプロイ、自動最適化
• メリット：海外アクセスが速い、HTTPS 自動、Preview 環境
• デメリット：国内からはやや遅い、無料版帯域 100GB/月

Netlify：

• 両方対応、設定も簡単
• メリット：無料枠が大きい、Functions 対応
• デメリット：ビルド速度は Vercel よりやや遅い

Cloudflare Pages：

• 両方対応、デプロイが速い
• メリット：グローバル CDN、無制限帯域、無料枠が魅力的
• デメリット：ビルド環境が不安定なことがある

GitHub Pages（静的ホスティング）：

• Astro：完璧に対応、設定が簡単
• Next.js：静的エクスポート（output: 'export'）が必要、一部機能制限
• メリット：完全無料、GitHub Actions 自動デプロイ
• デメリット：国内アクセスは遅め、Server Components 非対応

国内アクセス最適化の提案

国内ユーザーを主ターゲットにするなら、次を意識してください。

1. CDN 選択：Cloudflare Pages は Vercel より国内アクセスが速い
2. フォント最適化：ローカルフォントまたは国内 CDN（Google Fonts は避ける）
3. サードパーティ：コメントは Disqus より Giscus（GitHub ベース）
4. 画像ホスティング：Alibaba Cloud OSS や Tencent Cloud COS を使い、Imgur は避ける

私のブログは Cloudflare Pages で、国内からのアクセス速度は悪くありません。

よくある問題と対処

Astro の限界：

• ❌ 高インタラクションアプリ（Dashboard、SaaS 製品）向きではない
• ❌ リアルタイムデータ更新は Next.js ほど柔軟でない
• ✅ 対処：静的コンテンツは Astro、動的機能は別サービス

Next.js の過剰設計：

• ❌ シンプルなブログには重すぎる
• ❌ App Router の学習曲線が急
• ✅ 対処：静的サイトだけなら Astro への切り替えを検討

パフォーマンス最適化 Checklist（共通）：

• ☑ 画像は WebP、Lazy Loading 設定
• ☑ フォントは font-display: swap で描画ブロック回避
• ☑ サードパーティスクリプトは遅延ロード（Google Analytics、広告）
• ☑ HTTP/2 と Brotli 圧縮を有効化
• ☑ 適切な Cache-Control ヘッダー

おすすめ学習リソース

Astro：

• 公式ドキュメント：明快、読めば基本は押さえられる
• Astro Blog Tutorial：公式チュートリアル、ブログ構築を手取り足取り
• Starlight ドキュメント：ドキュメントサイトなら必読

Next.js：

• 公式ドキュメント：網羅的だがやや冗長
• Next.js Learn：インタラクティブ、初心者向き
• App Router 移行ガイド：Pages Router からの移行必読

これらを読めば、開発に着手できます。

結論

ここまで語ってきました。まとめます。

Astro vs Next.js、絶対的な「どちらが上」はありません。シーン次第です。

私ならこう選ぶ：

• 個人ブログ、技術ドキュメント：Astro、説明不要
• 企業公式、LP：Astro、性能が競争力
• CMS 連携：更新頻度次第、低頻度なら Astro、高頻度なら Next.js
• 複雑アプリ、EC：Next.js、迷わない
• チームが React 中心：Next.js、学習コストが低い

私は最終的に Astro を選びました。理由は：

1. ブログコンテンツの 95% が静的で、React の重量級ランタイムは不要
2. Lighthouse 満点の爽快感、SEO ランキングも改善を実感
3. Markdown 処理が快適で、執筆効率が上がった

ただし、SaaS 公式（Demo、ユーザー Dashboard 付き）なら Next.js を選びます。動的機能が増えると Astro では足りなくなります。

今すぐ動く：

記事を読むだけでなく、10 分触ってみてください。両方で Hello World を組み、Lighthouse を回し、数字の差を体感する。百篇の比較記事より効きます。

# Astro
npm create astro@latest test-astro
cd test-astro && npm install && npm run dev

# Next.js
npx create-next-app@latest test-nextjs
cd test-nextjs && npm run dev

構築後、Chrome DevTools で Lighthouse を実行。性能差は数字が物語ります。

最後に：フレームワークは道具、コンテンツが本体。Astro でも Next.js でも、質の高い記事を書くことが最重要。フレームワーク選びを書き始めない口実にしないでください。

質問はコメント欄で。できる限り返信します。サイト構築、うまくいくことを。