はじめに

とある開発をしていた時に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の場合はどうなるかは別記事でまとめたいと思います。