static-rendering

静的レンダリング

SSRについての説明から、サーバーでのリクエスト処理時間が長いとTTFBに悪影響を及ぼすことがわかっています。同様に、CSRでは、大きなJavaScriptバンドルのダウンロードと処理に時間がかかるため、アプリケーションのFCP、LCP、TTIに悪影響を及ぼす可能性があります。

静的レンダリング、または静的生成（SSG）は、サイトのビルド時に生成した事前レンダリング済みのHTMLコンテンツをクライアントに配信することで、こうした問題の解決を目指します。

使用する場合

• リクエストごとに変更されない「会社概要」ページ、ブログ記事、商品一覧などの静的コンテンツに使用します
• CDNから配信される静的HTMLによって、可能な限り高速なTTFBを実現したい場合に役立ちます

使用しない場合

• ユーザーダッシュボードやリアルタイムフィードなど、リクエストごとに変化する、動的でパーソナライズされたコンテンツの場合
• ISRを使わないとビルド時間が現実的でなくなるほど、データセットが大きい場合
• ビルド時に事前レンダリングできない、認証で保護されたコンテンツが必要なページの場合

手順

• ビルド時にデータを取得するには、getStaticProps（Pages Router）または非同期コンポーネント（App Router）を使用します
• 動的ルートを事前レンダリングするには、getStaticPaths／generateStaticParamsを使用します
• 定期的な更新が必要なページでは、Incremental Static Regeneration（ISR）を検討します
• エッジでキャッシュされたパフォーマンスを実現するため、CDNにデプロイします

詳細

ユーザーがアクセスできる各ルートに対応する静的HTMLファイルが、事前に生成されます。これらの静的HTMLファイルはサーバーまたはCDN上に配置でき、クライアントからリクエストされると取得されます。

静的ファイルはキャッシュすることもできるため、より高い回復力が得られます。HTMLレスポンスはあらかじめ生成されているため、サーバーでの処理時間はごくわずかとなり、TTFBの短縮とパフォーマンスの向上につながります。理想的なシナリオでは、クライアント側のJSを最小限に抑え、クライアントがレスポンスを受信してすぐに静的ページを操作できるようにします。その結果、SSGによってFCP／TTIの高速化を実現できます。

基本構造

名前が示すとおり、静的レンダリングは、ログイン中のユーザー（パーソナライズされたおすすめなど）に応じてページをカスタマイズする必要がない静的コンテンツに適しています。そのため、ウェブサイトの「会社概要」や「お問い合わせ」、_ブログ_のページ、またはECアプリの商品ページなどの静的ページは、静的レンダリングに適しています。Next.js、Gatsby、VuePressなどのフレームワークは静的生成をサポートしています。

Next.js：

// pages/about.js

export default function About() {
  return (
    <div>
      <h1>About Us</h1>
      {/* ... */}
    </div>
  );
}

サイトをビルドするとき（next build）、このページは/aboutルートからアクセスできるabout.htmlというHTMLファイルに事前レンダリングされます。

データを使ったSSG

「会社概要」や「お問い合わせ」ページのような静的コンテンツは、データストアからデータを取得せず、そのままレンダリングできます。一方、個別のブログページや商品ページのようなコンテンツでは、データストアのデータを特定のテンプレートと組み合わせ、ビルド時にHTMLへレンダリングする必要があります。

一覧ページ - すべての項目

Next.jsでは、ページコンポーネントで関数getStaticProps()をエクスポートすることで実現できます。この関数はビルド時にビルドサーバー上で呼び出され、データを取得します。

// This function runs at build time on the build server
export async function getStaticProps() {
  return {
    props: {
      products: await getProductsFromDatabase(),
    },
  };
}

// The page component receives products prop from getStaticProps at build time
export default function Products({ products }) {
  return (
    <>
      <h1>Products</h1>
      <ul>
        {products.map((product) => (
          <li key={product.id}>{product.name}</li>
        ))}
      </ul>
    </>
  );
}

この関数はクライアント側のJSバンドルに含まれないため、データベースからデータを直接取得する用途にも使用できます。

個別の詳細ページ - 項目ごと

個別の詳細ページでは、動的ルートと組み合わせて関数getStaticPaths()を使用できます。

// pages/products/[id].js

export async function getStaticPaths() {
  const products = await getProductsFromDatabase();

  const paths = products.map((product) => ({
    params: { id: product.id },
  }));

  // fallback: false means pages that don't have the correct id will 404.
  return { paths, fallback: false };
}

// params will contain the id for each generated page.
export async function getStaticProps({ params }) {
  return {
    props: {
      product: await getProductFromDatabase(params.id),
    },
  };
}

export default function Product({ product }) {
  // Render product
}

SSG - 主な考慮事項

1. 大量の HTML ファイル： ユーザーがアクセスする可能性のあるすべてのルートについて、個別の HTML ファイルを生成する必要があります。大量の HTML ファイルの管理は困難になる場合があります。

2. ホスティングへの依存： SSG サイトが非常に高速に動作し、すばやく応答するには、HTML ファイルを保存して配信するホスティングプラットフォームも優れている必要があります。適切に調整された SSG サイトを複数の CDN で直接ホストし、エッジキャッシュを活用すれば、最高のパフォーマンスを実現できます。

3. 動的コンテンツ： コンテンツが変更されるたびに、SSG サイトをビルドして再デプロイする必要があります。コンテンツの変更後にサイトがビルドおよびデプロイされていないと、表示されるコンテンツが古いままになる可能性があります。そのため、SSG は動的なコンテンツが多い場合には適していません。

ソース

• patterns.dev/react/static-rendering