本記事に関して

Next.jsは レンダリング戦略 を細かく制御できることが強みとされています。ただそれが実際にパフォーマンスやUXにどれほどの影響があるのかがわからなかったため、各レンダリング戦略が体感でき、且つパフォーマンスが計測できるサイトを作ってみました。
サーバーサイドレンダリング (SSR)、静的サイト生成 (SSG)、クライアントサイドレンダリング (CSR)、パーシャル・プリレンダリング (PPR)の4つが比較できるようになっています。
https://next-performance-test-ten.vercel.app/

技術選定と実装内容

技術選定

使用言語・フレームワーク

言語: TypeScript 5
フレームワーク: Next.js 15.3.6
UIライブラリ: React 19.0.0
スタイリング: Tailwind CSS 4
開発環境: Turbopack
ホスティング: Vercel

計測ツール

Web Vitals: web-vitals 5.0.3
- 標準のCore Web Vitals（FCP, LCP, TTFB, INP）を計測
カスタムメトリクス:
- TTCV (Time To Content Visible): 最初のカードが表示されるまでの時間
- ListRendered: リストのDOM描画完了時間
- FirstImageLoaded: 最初の画像の読み込み完了時間
Server-Timing API: サーバーサイドの処理時間を詳細に計測
- アプリケーション層の処理時間
- 外部API取得時間

実装内容

リポジトリは以下に公開しています

データフェッチの仕組み

各レンダリング戦略で異なるデータフェッチ方法を採用しています。

1. CSR (Client-Side Rendering)

内部API (/api/posts) 経由でJSONPlaceholder APIからデータを取得
クライアントサイドで400msの人工遅延を追加

2. SSR (Server-Side Rendering)

内部API経由でpostsとusersを並列取得
サーバーサイドでデータを統合・加工
700msの人工遅延を追加（DB結合や集計処理を模倣）

3. SSG (Static Site Generation)

ビルド時にJSONPlaceholder APIから直接データ取得
force-staticで静的生成を強制

4. PPR風 (Streaming + Suspense)

静的部分は即座に表示、動的部分はSuspenseでストリーミング
動的コンテンツは600msの遅延後にストリーミング配信

人工遅延の設定

リアルな環境を模倣するため、各箇所に人工的な遅延を追加しています。

エンドポイント/処理	遅延時間	目的
`/api/posts`	300ms	サーバー処理・外部API取得の遅延を模倣
`/api/users`	150ms	軽量なAPI取得を想定
SSR追加処理	700ms	DB結合や複雑な集計処理を模倣
CSRクライアント処理	400ms	JS実行・API待ちの体感差を強調
PPR動的部分	600ms	動的コンテンツ取得の遅延を模倣

これらの遅延により、各レンダリング戦略のパフォーマンス特性を明確に比較できるようになっています。

今回はAPIやページの表示内容が軽量のため、人口遅延を入れないと計測結果にほとんど差がでませんでした。つまりは軽量なページであればどの手法でもさほどUXに影響はないです。ただしSEOには影響があるのでご注意ください。

測定結果

サーバーサイドレンダリング (SSR)

メトリクス	1回目 (ms)	2回目 (ms)	3回目 (ms)	4回目 (ms)	5回目 (ms)	平均 (ms)
TTFB	44	30	29	40	33	35
FCP	112	192	72	104	112	118
LCP	112	192	72	104	112	118
TTCV	2220	1559	1582	1418	1356	1627
ListRendered	2214	1554	1578	1414	1350	1622
FirstImageLoaded	2225	1554	1578	1408	1345	1622

静的サイト生成 (SSG)

メトリクス	1回目 (ms)	2回目 (ms)	3回目 (ms)	4回目 (ms)	5回目 (ms)	平均 (ms)
TTFB	41	42	36	35	43	39
FCP	124	112	112	148	124	124
LCP	124	112	112	148	124	124
TTCV	45	38	41	40	51	43
ListRendered	40	33	37	36	48	39
FirstImageLoaded	40	33	37	31	42	37

クライアントサイドレンダリング (CSR)

メトリクス	1回目 (ms)	2回目 (ms)	3回目 (ms)	4回目 (ms)	5回目 (ms)	平均 (ms)
TTFB	36	35	82	39	34	45
FCP	120	120	164	104	104	122
LCP	120	120	164	104	104	122
TTCV	1304	1275	1340	1383	1346	1330
ListRendered	1300	1270	1337	1378	1343	1326
FirstImageLoaded	1300	1270	1332	1378	1337	1323

パーシャル・プリレンダリング (PPR)

メトリクス	1回目 (ms)	2回目 (ms)	3回目 (ms)	4回目 (ms)	5回目 (ms)	平均 (ms)
TTFB	41	43	35	41	47	41
FCP	116	108	104	120	128	115
LCP	116	108	104	120	128	115
TTCV	1350	1216	1276	1193	1258	1259
ListRendered	1346	1213	1273	1189	1255	1255
FirstImageLoaded	1345	1205	1267	1184	1250	1250

期待される傾向、結果の分析

TTFB (Time To First Byte)

サーバーがリクエストを受け取ってから、レスポンスの最初の1バイトをブラウザに送信するまでの時間です。

期待される傾向

SSG (静的生成) と PPR (部分的な事前レンダリング) は、事前にHTMLが生成・キャッシュされるため、非常に短くなる傾向があります。SSR (サーバーサイドレンダリング) と CSR (クライアントサイドレンダリング) は、リクエストごとに処理が走るため、SSG/PPRより長くなります。特にSSRは毎回サーバーでHTMLを生成するため長くなりがちです。

FCP (First Contentful Paint) & LCP (Largest Contentful Paint)

FCP: 画面に最初のコンテンツ（テキスト、画像など）が描画されるまでの時間です。
LCP: 画面内の最大コンテンツ要素（メイン画像や大きなテキストブロック）が描画されるまでの時間です。

期待される傾向:

SSG/SSR/PPRは、HTMLにコンテンツが含まれた状態で配信されるため、ブラウザは受け取り次第すぐに描画を開始でき、FCP/LCPが短くなる傾向があります。
CSRは、空のHTMLを受け取った後、JavaScriptをダウンロード・実行して初めてコンテンツを生成・描画するため、FCP/LCPが長くなる傾向があります。

TTV (Time To View/Total Time to View) & リスト描画時間

この計測では、「TTCV (Time To Contentful View)」や「ListRendered」「FirstImageLoaded」というカスタムメトリクスが使用されています。これらは、ページが完全に表示され、コンテンツが利用可能になるまでの時間を示す指標です。

期待される傾向:

SSR/CSR/PPRは、データフェッチやJavaScriptの処理（ハイドレーションなど）が関与するため、SSGよりも時間がかかる傾向があります。
SSGは静的なコンテンツなので、TTCVやListRenderedがFCP/LCPとほぼ同等で、非常に短くなることが期待されます。
SSR/CSR/PPRは、FCP/LCPからTTCV/ListRenderedまでの間に、JavaScriptのハイドレーションや動的データのロード時間が発生し、時間の差が生まれる傾向があります。

結果の分析

✅️ 本来出るべき結果が出ている点

SSG/PPRのTTFBが最も短い: 静的・キャッシュ可能なコンテンツの高速配信という利点が明確に出ています。
SSR/CSR/PPRのTTCV/ListRenderedが長い: FCP/LCPとの間に大きな差があり、初期表示後のJavaScript処理（ハイドレーションなど）に時間がかかっているという動的なレンダリング戦略の一般的なトレードオフが明確に表れています。
SSGが最終的なコンテンツ描画（TTCV/ListRendered）で最も速い: 静的なコンテンツは最速であるという基本原則通りです。

⚠️ 意外な点（良好な結果ではある）

CSRのFCP/LCPがSSG/SSRとほぼ同等: 通常はCSRが最も遅くなるはずですが、この計測では非常に高速です。これは、計測対象のページが非常にシンプルで、Javascriptのバンドルサイズが小さいからであると考えられます。

感想

SSGが使える場合は積極的に使用すべきで、それが難しい場合はISRを使ってなるべく静的データを作っておくことで表示スピードが高速になりSEO対策にもなると思いました。また、SSRとCSRはレスポンススピードによってUXが左右される傾向があるため、個人的にはPPRが最もストレスフリーだと感じました。Next14以降はPPRはStableになったため積極的に使っていこうと思います。