Vercel関数を東京リージョンに固定して体感速度を改善した話 — 太平洋往復の解消

この記事のまとめ

• ダッシュボードが遅い原因は「Vercel関数が米国・DBが東京」で毎回太平洋を往復していたこと
• x-vercel-id レスポンスヘッダで、どのリージョンで実行されたかを確認できる
• vercel.json の regions で東京固定 + クエリの並列化で、社内計測で数秒 → 0.2秒前後に短縮

「ダッシュボードの画面遷移が数秒かかる」——この体感の遅さを調査し、原因を特定して改善した記録です。推測ではなく、実測で切り分けました。

症状と切り分け

画面遷移で約3秒。まず「サーバーの初動（TTFB）」と「中身の取得」のどちらが遅いかを切り分けたところ、初動は速く、ページ内のデータ取得が遅いと分かりました。

各クエリ自体はデータベース上では数ミリ秒と高速でした。にもかかわらず全体が遅い。ここで疑ったのが、実行場所（リージョン） です。

原因①：太平洋を往復していた

レスポンスヘッダ x-vercel-id を見ると、関数が 米国東部リージョン（iad1） で実行されていました。一方、データベース（Supabase）は 東京。つまりクエリのたびに、日本↔米国の往復が発生していたのです。

ヘッダはこう見えます（イメージ）。

x-vercel-id: hnd1::iad1   ← 受け口は東京(hnd1)だが、実行は米国(iad1)

クエリが数回あれば、そのたびに太平洋を往復し、レイテンシが積み上がります。

原因②：クエリを直列で待っていた

もう1つ、ホーム画面が複数の集計を 直列（1つずつ順番に） 取得していました。往復の遅延が、そのまま回数分だけ積み重なる状態です。

対策

リージョンを東京に固定

vercel.json にリージョン指定を追加し、関数を東京（hnd1）で実行するようにしました。

{ "regions": ["hnd1"] }

これで x-vercel-id が hnd1::hnd1 となり、関数とDBがどちらも東京に。往復の遅延が解消されました。

クエリを並列化

直列で待っていた集計取得を Promise.all で並列化し、あわせて重複していた取得を1つに統合しました。

結果

社内計測で、ホーム画面の表示時間が 数秒から 0.2秒前後 に短縮されました。ポイントは、キャッシュに頼らず処理そのものを速くしたこと。表示されるデータは常に最新のままです。

学び

• 「クエリは速いのに画面は遅い」ときは、DBの速度だけでなく 関数とDBの物理的な距離（リージョン） を疑う。
• x-vercel-id は、実行リージョンを確認する手軽で強力な手がかり。
• 往復コストが高い環境では、直列の待ち合わせが致命的になる。並列化の効果が大きい。

まとめ

体感の遅さの正体は、米国と東京の往復でした。リージョン固定と並列化という2つの対策で、キャッシュなしのまま体感を大きく改善できました。SSRやダッシュボードが遅いと感じたら、まず実行リージョンとDBの位置関係を確認してみてください。