Server Componentsの生成が実行されるタイミングについて

Server Componnentは大きく3つのタイミングで生成が実行されます。

1. ビルド時
Next.jsアプリケーションをビルドするタイミング（npm run build等）でServer Componentsの生成が行われます。ビルド時にサーバでHTML等の生成が行われるので、ユーザはすぐにコンテンツを見ることができます。ただし、ビルド時にデータ取得を行うので、リアルタイムなデータ反映はできません。

2. 一定時間経過後
該当ページに最初のリクエストが送られてから一定時間経過後にそのページのServer Componentsの生成が行われます。
リアルタイムなデータ反映とまではいきませんが、概ねパフォーマンスを維持したまま新しい情報の配信が可能となります。

3. リクエスト時
ユーザからリクエストを受け取ったタイミングでHTML等の生成がサーバで行われる。これにより、リアルタイムなコンテンツを提供が可能になります。ただしリクエストを受けてからデータ取得、HTML、CSSの組み立て等が行われるので、パフォーマンスは少し落ちます。

Next.js13では、1のビルド時にデータを取得することをStatic Data Fetching、ビルド時に生成したHTMLをユーザの画面上に表示することをStatic Renderingと定義しています。

2の一定時間経過後にServer Componentsが生成されるようにするにはStatic Data Fetchingのオプションであるrevalidateを設定する必要があります。

3のリクエスト時にサーバ上でデータの取得を行うことをDynamic Data Ferching、リクエスト時に生成したHTMLをユーザの画面上に表示することをDynamic Renderingと定義しています。

なぜServer Componentsを使う必要があるのか

Client Componentsだけでもアプリケーションは作ることができます。

Server ComponentsはClient Componentsと比較して、以下のようなメリットが存在します。

- パフォーマンスが高い
- Googleのクローラーが認識できる
- SEOの向上につながる

パフォーマンスについては、先ほど解説したとおりで、ユーザの環境に依存しない画面表示ができるためです。

一般的にClient Componentsで構成されるアプリケーションをSPA（シングルページアプリケーション）と呼びます。

SPAはリアルタイムな更新が可能であったりUI（ユーザインターフェース）的に優れているのですが、Googleのクローラーからは正確に認識されづらいというデメリットがあります。

Googleのクローラーに正確に認識されることによって、Googleなどの検索エンジンの検索結果で上位に表示されるようになります。

しかし、Googleのクローラーはせっかちなところがあるので、HTML、CSSの組み立てまでは待ってくれますが、JavaScriptで取得したデータを展開させるところまでは待ってくれません。

そのため、Googleのクローラーはデータが入っていないHTMLをそのWebページのコンテンツとして認識するので、コンテンツが充実していないと判断し、検索結果で上位表示をしないようになります。

Server Componentsを使うことによって、これを避けることができます。

Next.js12以前と比較して理解するServer Components

Next.js12以前にもNext.js13のServer Componentsのような仕組みはあります。
しかし、Server Componentsより柔軟性に欠けています。

styled-componentsの使い方について解説！Next.jsでの導入方法

目次

RECOMMEND