はじめに
とある開発をしていた時にproxy.tsを入れたら想定していなかった挙動が起きたので、どういう変化があるのかを整理するためにまとめてみました。
この記事ではPages Routerの場合について説明します。
前提
この記事は以下の環境での説明になります。
- Next.js（Pages Router） 16.0.7
- TypeScript
SSG と SSR とは
今回起きた挙動変化がプリフェッチ（後述）によるもので、SSG はプリフェッチをするがSSR は基本的にはしないという説明を見かけたので、改めて SSG と SSRを整理しました。
SSG
SSG（Static Site Generation） とはビルド時に静的HTMLを事前に作成しておき、リクエストがあった時にそのHTMLを返す仕組みです。
SSR
SSR（Server Side Rendering） とはページ遷移時にサーバー側で必要なデータを取得し、表示するHTMLを作成して返す仕組みです。
プリフェッチとは
プリフェッチとは、新しいページへ遷移する前にリンク先の静的リソース（JS・CSS・画像等）を事前に取得する仕組みです。
これによって、高速に次のページを表示することができるメリットがあります。
本番環境でしか確認できないので、開発環境で確認するにはnpm run startでアプリを見る必要があります。
SSG と SSR でのプリフェッチの違い
SSG と SSR でプリフェッチの挙動が変わります。
SSG の場合は全てのページに対してプリフェッチします。具体的にはリンクにホバーすると遷移先のページデータ（JSON）がダウンロードされます。
SSR の場合は基本的にはプリフェッチされません。SSG の時と異なりリンクにホバーしても何も起こりません。
まとめると以下のようになります。
| SSG の場合 | SSR の場合 | |
|---|---|---|
| プリフェッチ有無 | ◯ | ×（例外あり） |
proxy.tsを使うと…
SSG は変わりませんが、SSR の場合は挙動が変わります。
元々は遷移先のページのリソースを読み込んでいませんでしたが、proxy.tsを入れることでリソースを読み込むように変わりました。
proxy.tsは以下のコードを入れています。
import { NextRequest, NextResponse } from "next/server";
export const proxy = (request: NextRequest) => {
// リクエスト/レスポンス前処理
// リダイレクト、ヘッダー操作、など
return NextResponse.next();
};
proxy.tsを入れる前
proxy.tsを入れた後
よって、先ほどの表はこのように変わります。
| SSG の場合 | SSR の場合 | |
|---|---|---|
| プリフェッチ有無 | ◯ | △（proxy.tsを入れると⚪︎） |
proxy.tsを使ってもプリフェッチされないようにしたい場合
proxy.tsを使ってもプリフェッチされないようにしたい場合は以下の設定をnext.config.tsに入れるとプリフェッチが行われなくなります。
experimental: {
proxyPrefetch: "strict", // デフォルトは "flexible"
},
まとめ
- リンク先の静的リソースを事前に作成しておく仕組みをプリフェッチと呼ぶ
- SSG ではプリフェッチをするが SSR ではプリフェッチは基本的には行われない
- ただし、proxy.tsを使うと SSR でもプリフェッチが行われるようになる
App Routerの場合はどうなるかは別記事でまとめたいと思います。