静的レンダリング

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

静的レンダリングまたは静的生成（SSG）は、サイトがビルドされたときに生成された事前レンダリングされた HTML コンテンツをクライアントに配信することで、これらの問題の解決を試みます。

使用する場合

• About ページ、ブログ投稿、リクエストごとに変わらない製品リストなど、静的コンテンツに使用します
• CDN で提供される静的 HTML を介して最速の TTFB を実現したい場合に有効です

使用しない場合

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

説明

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

詳細

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

静的ファイルはキャッシュされることもあり、より高い復元力を提供します。HTML レスポンスが事前に生成されるため、サーバー上の処理時間は無視できるレベルであり、より高速な TTFB とより良いパフォーマンスが実現されます。理想的なシナリオでは、クライアント側の JS は最小限であり、静的ページはレスポンスがクライアントで受け取られた直後にインタラクティブになるべきです。その結果、SSG はより高速な FCP/TTI を実現するのに役立ちます。

基本構造

名前が示すように、静的レンダリングは静的コンテンツに最適であり、ページはログインユーザーに基づいてカスタマイズする必要がありません（例：パーソナライズされたレコメンデーション）。したがって、Websites の「About Us」、「Contact Us」、Blog ページ、または e-commerce アプリの製品ページなどの静的ページは、静的レンダリングの理想的な候補です。Next.js、Gatsby、VuePress などのフレームワークは静的生成をサポートしています。

Next.js:

// pages/about.js

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

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

データ付き SSG

「About us」または「Contact us」ページのような静的コンテンツは、データストアからデータを取得せずにそのままレンダリングされる場合があります。ただし、個別のブログページや製品ページなどのコンテンツの場合、データストアからのデータを特定のテンプレートとマージした後、ビルド時に HTML にレンダリングする必要があります。

リストページ - すべてのアイテム

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

// この関数はビルド時にビルドサーバー上で実行されます
export async function getStaticProps() {
  return {
    props: {
      products: await getProductsFromDatabase(),
    },
  };
}

// ページコンポーネントはビルド時に getStaticProps からプロダクト props を受け取ります
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 は、正しい id を持たないページが 404 になることを意味します。
  return { paths, fallback: false };
}

// params には生成された各ページの id が含まれます。
export async function getStaticProps({ params }) {
  return {
    props: {
      product: await getProductFromDatabase(params.id),
    },
  };
}

export default function Product({ product }) {
  // 製品をレンダリング
}

SSG - 主要な考慮事項

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

2. ホスティングの依存性： SSG サイトが超高速で迅速に応答するには、HTML ファイルを保存して提供するために使用されるホスティングプラットフォームも優れている必要があります。適切にチューニングされた SSG ウェブサイトが複数の CDN に直接ホストされている場合、エッジキャッシングの利点を生かして最高のパフォーマンスが可能になります。

3. 動的コンテンツ： SSG サイトはコンテンツが変更されるたびにビルドと再デプロイが必要です。コンテンツ変更後にサイトがビルド＆デプロイされていない場合、表示されるコンテンツは古い可能性があります。これにより、SSG は動的コンテンツに不向きになります。

ソース

• patterns.dev/react/static-rendering