M

MLOG

日本語

サーバーサイドレンダリング（SSR）と静的サイト生成（SSG）の重要な違いを理解し、Next.js App Routerの力を最大限に引き出しましょう。最適なパフォーマンスとSEOを実現するために、各戦略をいつ使用すべきかを学びます。

Next.js App Router: SSR 対 SSG - 包括的ガイド

Next.jsのApp Routerは、Reactアプリケーションの構築方法に革命をもたらし、パフォーマンス、柔軟性、開発者体験を向上させました。この新しいアーキテクチャの中心となるのが、サーバーサイドレンダリング（SSR）と静的サイト生成（SSG）という2つの強力なレンダリング戦略です。適切なアプローチを選択することは、アプリケーションのパフォーマンス、SEO、ユーザー体験を最適化するために不可欠です。この包括的なガイドでは、Next.js App Routerの文脈におけるSSRとSSGの詳細を掘り下げ、プロジェクトに合わせた情報に基づいた意思決定を支援します。

基本を理解する：SSRとSSG

Next.js App Routerの詳細に入る前に、SSRとSSGについて明確に理解しておきましょう。

サーバーサイドレンダリング（SSR）

SSRは、リクエストごとにサーバー上でReactコンポーネントをHTMLにレンダリングする技術です。サーバーは完全にレンダリングされたHTMLをクライアントのブラウザに送信し、ブラウザはそのページをハイドレートしてインタラクティブにします。

SSRの主な特徴：

静的サイト生成（SSG）

一方、SSGはビルド時にReactコンポーネントをHTMLに事前レンダリングします。生成されたHTMLファイルは、CDNやWebサーバーから直接提供されます。

SSGの主な特徴：

Next.js App RouterにおけるSSRとSSG：主な違い

Next.js App Routerは、ルート定義とデータフェッチ処理に新しいパラダイムを導入します。この新しい環境でSSRとSSGがどのように実装され、それらの主な違いが何かを探ってみましょう。

App Routerでのデータフェッチ

App Routerは、サーバーコンポーネント内で `async/await` 構文を使用した統一的なデータフェッチアプローチを提供します。これにより、SSRまたはSSGを使用しているかに関わらず、データフェッチのプロセスが簡素化されます。

サーバーコンポーネント： サーバーコンポーネントは、サーバー上でのみ実行される新しいタイプのReactコンポーネントです。これにより、APIルートを作成することなく、コンポーネント内で直接データをフェッチできます。

例（SSR）：

// app/blog/[slug]/page.js
import { getBlogPost } from './data';

export default async function BlogPost({ params }) {
  const post = await getBlogPost(params.slug);

  return (
    <div>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </div>
  );
}

この例では、`getBlogPost` 関数がリクエストごとにサーバーでブログ投稿データをフェッチします。`export default async function BlogPost` は、これがサーバーコンポーネントであることを示しています。

例（SSG）：

// app/blog/[slug]/page.js
import { getBlogPost } from './data';

export async function generateStaticParams() {
  const posts = await getAllBlogPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

export default async function BlogPost({ params }) {
  const post = await getBlogPost(params.slug);

  return (
    <div>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </div>
  );
}

ここでは、`generateStaticParams` 関数を使用して、ビルド時に利用可能なすべてのスラッグに対してブログ投稿を事前レンダリングします。これはSSGにとって重要です。

キャッシング戦略

Next.js App Routerは、SSRとSSGの両方のパフォーマンスを最適化するための組み込みキャッシングメカニズムを提供します。これらのメカニズムを理解することは不可欠です。

データキャッシュ： デフォルトでは、サーバーコンポーネントで `fetch` を使用してフェッチされたデータは自動的にキャッシュされます。これにより、同じデータに対する後続のリクエストはキャッシュから提供され、データソースへの負荷が軽減されます。

フルルートキャッシュ： ルートのレンダリングされた出力全体をキャッシュすることができ、パフォーマンスをさらに向上させます。`route.js` または `page.js` ファイルの `cache` オプションを使用してキャッシュの動作を設定できます。

例（キャッシュの無効化）：

// app/blog/[slug]/page.js

export const fetchCache = 'force-no-store';

import { getBlogPost } from './data';

export default async function BlogPost({ params }) {
  const post = await getBlogPost(params.slug);

  return (
    <div>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </div>
  );
}

この場合、`fetchCache = 'force-no-store'` はこの特定のルートのキャッシュを無効にし、データが常にサーバーから新しくフェッチされるようにします。

動的関数

`dynamic` ルートセグメント設定オプションを設定することで、ルートを実行時に動的として宣言できます。これは、ルートが動的関数を使用しているかどうかをNext.jsに通知し、ビルド時に異なる扱いをすべきかを示すのに役立ちます。

例（動的ルートセグメント）：

// app/blog/[slug]/page.js
export const dynamic = 'force-dynamic'; // static by default, unless reading the request

import { getBlogPost } from './data';

export default async function BlogPost({ params }) {
  const post = await getBlogPost(params.slug);

  return (
    <div>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </div>
  );
}

インクリメンタル静的再生成（ISR）

App Routerは、SSRとSSGの両方の利点を組み合わせたハイブリッドアプローチとして、インクリメンタル静的再生成（ISR）を提供します。ISRを使用すると、ページを静的に生成しつつ、指定された間隔でバックグラウンドで更新することができます。

ISRの仕組み：

  1. ページへの最初のリクエストが静的生成をトリガーします。
  2. 後続のリクエストは、静的に生成されたキャッシュから提供されます。
  3. バックグラウンドで、Next.jsは指定された時間間隔（revalidate時間）後にページを再生成します。
  4. 再生成が完了すると、キャッシュはページの新しいバージョンで更新されます。

ISRの実装：

ISRを有効にするには、`getStaticProps` 関数（`pages` ディレクトリ内）または `fetch` オプション（`app` ディレクトリ内）で `revalidate` オプションを設定する必要があります。

例（App RouterでのISR）：

// app/blog/[slug]/page.js
import { getBlogPost } from './data';

export default async function BlogPost({ params }) {
  const post = await getBlogPost(params.slug);

  return (
    <div>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </div>
  );
}

export const revalidate = 60; // 60秒ごとに再検証

この例では、ISRが60秒ごとにブログ投稿を再検証するように設定されています。これにより、サイト全体を再ビルドすることなく、静的コンテンツを新鮮に保つことができます。

適切な戦略の選択：実践ガイド

SSR、SSG、ISRのいずれを選択するかは、アプリケーションの特定の要件によって異なります。以下に意思決定のフレームワークを示します。

SSRを使用する場合：

例： 常に更新される記事や速報ニュースアラートがあるニュースサイト。また、リアルタイムで更新されるソーシャルメディアフィードにも適しています。

SSGを使用する場合：

例： あなたのスキルやプロジェクトを紹介する個人のポートフォリオサイト。めったに変更されない会社の「会社概要」ページ。

ISRを使用する場合：

例： 商品価格が毎日更新されるEコマースサイト。週に数回新しい記事が公開されるブログ。

Next.js App RouterでSSRとSSGを実装するためのベストプラクティス

最適なパフォーマンスと保守性を確保するために、Next.js App RouterでSSRとSSGを実装する際には、以下のベストプラクティスに従ってください。

高度な考慮事項

エッジ関数

Next.jsはエッジ関数もサポートしており、エッジネットワーク上でサーバーレス関数を実行できます。これは、A/Bテスト、認証、パーソナライゼーションなどのタスクに役立ちます。

ミドルウェア

ミドルウェアを使用すると、リクエストが完了する前にコードを実行できます。認証、リダイレクション、機能フラグなどのタスクにミドルウェアを使用できます。

国際化（i18n）

グローバルなアプリケーションを構築する際には、国際化が不可欠です。Next.jsはi18nの組み込みサポートを提供しており、Webサイトのローカライズ版を簡単に作成できます。

例（i18nの設定）：

// next.config.js
module.exports = {
  i18n: {
    locales: ['en', 'fr', 'es', 'de'],
    defaultLocale: 'en',
  },
}

実世界の例

さまざまな企業がNext.jsでSSR、SSG、ISRをどのように使用しているか、いくつかの実世界の例を見てみましょう。

結論

Next.js App Routerは、現代的なWebアプリケーションを構築するための強力で柔軟なプラットフォームを提供します。SSRとSSGの違い、そしてISRの利点を理解することは、レンダリング戦略について情報に基づいた決定を下すために不可欠です。アプリケーションの特定の要件を慎重に検討し、ベストプラクティスに従うことで、パフォーマンス、SEO、ユーザー体験を最適化し、最終的にはグローバルなオーディエンスに対応する成功したWebアプリケーションを作成できます。

アプリケーションのパフォーマンスを継続的に監視し、必要に応じてレンダリング戦略を適応させることを忘れないでください。Web開発の状況は常に進化しているため、最新のトレンドやテクノロジーに常に精通していることが成功には不可欠です。