Page Router vs App Router vs React Server Components

Reactエコシステムが進化するにつれて、Next.jsは開発者に多様なレンダリングオプションを提供しています。特に、Next.jsのPage Router SSR（サーバーサイドレンダリング）とReact Server Components（RSC）がありますね。今回の記事では、伝統的なNext.js Page RouterベースのSSRと、Next.js App RouterベースのSSR、そしてReact Server Componentsの違いについて見ていきましょう。

Next.js App RouterのServer Component = React Server Component？

Explain that NextJS Server Components among NextJs Docs are React-based

結論から言うと、Next.js App RouterのServer ComponentはReactのServer Componentを基に作られています。Reactチームが設計したServer Componentの核心的なアイデアをNext.jsが受け入れ、App Routerを通じてそれに合ったエコシステムを迅速に実装したのです。

ただし、Page RouterのSSRは少し異なります。React Server Componentが登場する前に、Next.jsがReactとSSRを一緒に使えるようにするために開発した独自の技術だからです。🤔

では、まずはPage Routerを見てみましょう！

Next.js Page RouterベースのSSR

Next.js Page Routerでは、SSRはgetServerSidePropsというメソッドを使って実装されます。このメソッドは、ページリクエスト時にサーバーでデータを取得する役割を担います。これにより、ユーザーはリクエスト時点で最新のデータに基づいたレンダリング済みのHTMLを受け取ることができ、これはSEO最適化や動的データ処理が重要なプロジェクトで役立ちます。

Page RouterにおけるSSRの主な特徴は、ページ単位のデータ取得と処理です。これは、各ページが独立してデータを取得しレンダリングするように設計されており、構成とデータ取得ロジックが明確に分離されています。しかし、すべてのページリクエストごとにサーバーで前処理を行うため、トラフィックの多いアプリケーションではサーバー負荷が増加する可能性があるという欠点があります。

例を見てみましょう。以下はgetServerSidePropsを使った基本的なSSRの実装です：

export async function getServerSideProps(context) {
  const res = await fetch('https://api.example.com/data');
  const data = await res.json();

  return {
    props: { data },
  };
}

export default function Page({ data }) {
  return <div>{data.title}</div>;
}

上記のコードでは、データはページロード時にサーバーで取得され、このデータはクライアントにHTMLとして送られます。このように、Page RouterベースのSSRは明確なデータフローとSEOフレンドリーなアーキテクチャを提供します。

Next.js App RouterとReact Server Components

Next.js 13でApp Routerが導入され、React Server Components（RSC）をデフォルトで使用する構成が可能になりました。RSCは、クライアントとサーバー間の境界をより効果的に設定し、アプリケーションのパフォーマンス最適化を目指します。App RouterベースのSSRは、従来のPage Routerよりも詳細でコンポーネント中心のアプローチを提供します。

App Routerはデータ取得とレンダリングの柔軟性を提供し、特定のコンポーネントをサーバーでレンダリングし、残りをクライアントで処理することができます。この方式により、初期ロード時間を短縮しつつ、サーバーの計算負荷を効率的に分散できます。RSCは、Reactの哲学である宣言的UIとサーバー中心のレンダリングを組み合わせ、開発者がクライアントとサーバーのパフォーマンスを最大化できるようにします。

RSCの主な利点は次のとおりです：

コンポーネント単位のデータフェッチ：必要なデータのみをサーバーから取得するため、トラフィックコストが削減されます。
クライアントのバンドルサイズ削減：不要なクライアントサイドJavaScriptを排除します。
柔軟な状態管理：クライアントとサーバー間で状態を効率的に共有できます。

次のセクションでは、App RouterとRSCを使用するコーディングパターンと、考慮すべき実務的な問題について見ていきます。

Next.js Page RouterベースのSSR vs App RouterベースのSSR

Next.jsは、Page Router（従来方式）とApp Router（React Server Componentsベース）という2つの主要なルーティング方式を提供します。どちらの方式もSSRをサポートしていますが、その動作方法と哲学は全く異なります。

1. Page RouterベースのSSR

Page RouterはNext.jsの伝統的なルーティング方式で、主にgetServerSidePropsを通じてサーバーサイドレンダリングをサポートします。この方式は、ReactコンポーネントをサーバーでHTMLにレンダリングした後、クライアントに送信し、ハイドレーションプロセスを通じてインタラクションを有効にします。

特徴と動作原理

データフェッチ：getServerSidePropsを使用してサーバーでデータを事前に取得します。
HTMLレンダリング：ReactコンポーネントをサーバーでHTML文字列に変換します。
ハイドレーション：クライアントでJavaScriptがイベントハンドラと状態を有効にします。
SEOフレンドリー：検索エンジンのクローラーがHTMLコンテンツに即座にアクセスできるようにします。

// Page RouterベースのSSRの例
export async function getServerSideProps() {
  const data = await fetch('https://api.example.com/data');
  return {
    props: { data },
  };
}

export default function Page({ data }) {
  return <div>{data.title}</div>;
}

限界点

バンドルサイズの増加：すべてのJavaScriptがクライアントに送信されるため、初期ロード速度が遅くなる可能性があります。
複雑なデータフロー：データフェッチロジックがコンポーネントの外部に位置するため、可読性が低下する可能性があります。

2. App RouterベースのSSR（React Server Components活用）

Next JServer Componentの例写真

Next.js 13から導入されたApp Routerは、React Server Componentsを中心に設計されており、全く異なるSSRアプローチを提供します。App RouterベースのSSRは、React Server Components（RSC）を活用して、サーバーでのみ実行されるコンポーネントとクライアントで実行されるコンポーネントを効率的に分離します。

特徴と動作原理

React Server Componentsの活用：サーバーでのみ実行されるコンポーネントを、HTMLの代わりにRSC Payloadというシリアライズされたデータとしてレンダリングします。
クライアント境界：'use client'を使用してクライアントコンポーネントを明示的に宣言します。
バンドルサイズの最適化：サーバー専用のロジックはクライアントに送信されないため、JavaScriptバンドルが小さくなります。
段階的なストリーミング：サーバーでレンダリングされたコンテンツをチャンク単位でストリーミングし、初期ロード速度を改善します。

// App RouterベースのSSRの例
// app/page.js (Server Component)
export default async function Page() {
  const data = await fetch('https://api.example.com/data');
  return <div>{data.title}</div>;
}

// components/Button.js (Client Component)
'use client';

export default function Button() {
  return <button>Click Me</button>;
}

利点

パフォーマンス最適化：サーバー専用コンポーネントにより、クライアントのJavaScriptロードを最小化します。
データフェッチの簡素化：コンポーネント自体でデータを直接フェッチします。
段階的レンダリング：データが到着次第コンテンツをレンダリングし、ユーザーエクスペリエンスを向上させます。

限界点

学習曲線：従来のPage Router方式に慣れている開発者にとっては新しいパラダイムです。
限定されたクライアント状態管理：サーバーコンポーネント内では状態管理フック（useState、useEffect）は使用できません。

React Server Components（RSC）

React Server Componentsは、React 18で導入された新しい概念で、Next.js App Routerの核心的な基盤となります。RSCはサーバーでのみ実行されるコンポーネントを定義し、クライアントにはそのコンポーネントの結果データをシリアライズされた形式で送信します。

RSCの特徴

サーバー専用実行：コンポーネントはサーバーでのみレンダリングされ、クライアントには送信されません。
状態なし：状態管理フックの使用はできず、純粋なレンダリングロジックに集中します。
直接的なデータフェッチ：データベースやファイルシステムなどのリソースに直接アクセス可能です。

// React Server Componentの例
async function Post({ id }) {
  const post = await fetch(`https://api.example.com/posts/${id}`);
  return <div>{post.title}</div>;
}

RSCの強み

バンドルサイズの削減：サーバー専用のコードがクライアントバンドルから除外されます。
データアクセスの簡素化：別のAPIレイヤーなしでデータソースに直接アクセス可能です。
ストリーミングのサポート：大規模なページを段階的にレンダリングできます。

私見とまとめ

Next.jsが2025年になってもウェブのフルスタックフレームワークで1位を維持している理由は、まさにこのような技術革新への俊敏性と実用性にあると考えられます。急速に変化するITトレンドに合わせた継続的なアップデート、実務中心の機能提供、そして開発生産性を最大化する哲学が組み合わさり、多くの開発者が信頼して選択するフレームワークとして定着したのだと思います！

メタデータ

Meta Title
Next.js SSR: Page Router vs App Router vs React Server Components

Meta Description
Next.jsのPage RouterとApp RouterにおけるSSRの違い、そしてReact Server Components（RSC）の核心概念を比較・分析します。SEO最適化からパフォーマンス改善まで、各レンダリング方式を理解しましょう。