画面はどこで作られるか

1. 「画面を作る」とはどういうことか

第1章で、ブラウザ（客席）がサーバー（厨房）からHTMLを受け取って表示する、という流れを見ました。では、そのHTMLはいつ、どこで作られるのでしょうか。

部品（コンポーネント）とデータを組み合わせて、最終的なHTMLを作り上げることをレンダリングと呼びます。料理でいえば「調理」です。Next.jsの大きな特徴は、この調理をどこで・いつ行うかを、ページや部品ごとに選べることにあります。

この章は少し長めですが、ここが分かると、開発者の説明やAIの回答が一気に理解しやすくなります。

2. 3つの調理方法：CSR・SSR・SSG

CSR（クライアントサイド・レンダリング）：客席で調理する

サーバーは、ほぼ空っぽのHTMLと「調理手順書」（JavaScript）だけを送り、ブラウザの中で画面を組み立てる方法です。Reactだけで作ったサイトは基本的にこの方式です。

• 良い点：一度表示されれば、画面の切り替えがなめらか。
• 弱い点：最初の表示まで時間がかかり、その間は真っ白になりがち。検索エンジンに中身が伝わりにくい。

SSR（サーバーサイド・レンダリング）：注文ごとに厨房で調理する

アクセスがあるたびに、サーバーで最新のデータを使ってHTMLを作り、完成品を送る方法です。

• 良い点：いつでも最新の内容。届いた時点で中身があるので、表示が速く検索にも強い。
• 弱い点：アクセスのたびに調理するため、サーバーの負担が増える。

SSG（静的サイト生成）：作り置きしておく

公開前の準備（ビルド）のときに、あらかじめHTMLを作り置きしておき、アクセスがあればそれを出すだけの方法です。

• 良い点：最も速く、サーバーの負担も最小。
• 弱い点：内容を変えるには作り直しが必要。

さらに、作り置きを「60秒ごと」「記事が更新されたとき」などに自動で作り直すこともできます。これはISR（インクリメンタル静的再生成）や再検証（revalidate）と呼ばれ、作り置きの速さと内容の新しさを両立させる方法です。

3. サーバーコンポーネントとクライアントコンポーネント

App Routerでは、ページ単位だけでなく部品単位でも「どこで動かすか」を分けます。

App Routerでは、部品は何も書かなければサーバーコンポーネントになります。サーバーで動くので、データベースに直接つないだり、秘密の情報を安全に扱えたりします。また、部品のプログラム自体はブラウザに送られないため、ページが軽くなります。

一方、クリックや入力に反応する部品は、ブラウザの中で動く必要があります。そういう部品のファイルの先頭には、次の1行を書きます。

"use client";

// この下に、ボタンや入力欄など「動きのある部品」を書く

「この部品は客席（ブラウザ）でも動かします」という宣言です。

ハイドレーション：届いた画面に「命を吹き込む」

サーバーで作られたHTMLは、見た目は完成していますが、まだボタンを押しても反応しません。そこへJavaScriptが届き、ボタンなどに動きを結び付ける作業をハイドレーション（水分を与える、の意味）と呼びます。乾燥食品にお湯を注いで食べられる状態にするイメージです。エラーメッセージで「Hydration」という言葉を見かけたら、「サーバーで作った画面と、ブラウザで作った画面が食い違った」という意味であることが多いです。

4. キャッシュ：作ったものを取っておく

一度作ったものや取り出したデータを保存しておき、次から再利用する仕組みをキャッシュと呼びます。同じ料理を何度も一から作らず、作り置きを出すことで速くなります。

ただし、キャッシュには「古い内容が表示され続ける」という落とし穴もあります。「データを更新したのに画面が変わらない」というトラブルの多くは、キャッシュが原因です。

Next.jsのキャッシュの扱いは、バージョンによって考え方が変わってきました。現在は、基本的には毎回新しく作り、作り置きしたい部分を開発者が明示する方針です。16系では、作り置きしたい部品や処理に "use cache" という印を付ける方式が導入されています。

5. 少しずつ届ける：ストリーミング

ページの一部だけデータの取得に時間がかかる場合、Next.jsは準備できた部分から先に表示し、遅い部分は後から差し込むことができます。これをストリーミングと呼びます。

コース料理で、前菜から順に運ばれてくるイメージです。メインディッシュ（遅いデータ）を待つ間も、お客さんは前菜を食べ始められます。第2章で見た loading.tsx は、遅い部分の場所に「準備中」の表示を出すための仕組みでした。