將 Vercel 函式固定在東京區域以改善體感速度 — 解決橫跨太平洋的往返問題

本文重點

• 儀表板變慢的原因是「Vercel 函式在美國、資料庫在東京」，每次都要橫跨太平洋往返
• 透過 x-vercel-id 回應標頭，可以確認程式碼實際是在哪個區域執行的
• 利用 vercel.json 的 regions 設定將執行區域固定在東京，並將查詢並行化後，內部實測從數秒縮短到約 0.2 秒

「儀表板畫面切換要花上數秒」——這篇文章記錄了我們如何調查這種體感上的延遲、找出原因並加以改善。我們不是憑猜測，而是透過實測來逐步排查的。

症狀與排查

畫面切換大約需要 3 秒。首先排查「伺服器的初始回應（TTFB）」與「內容的取得」哪一個比較慢，結果發現初始回應很快，問題出在頁面內的資料取得上。

在資料庫端，每個查詢本身其實只需要數毫秒，速度相當快。但整體卻很慢。於是我們開始懷疑**執行位置（區域）**的問題。

原因一：橫跨太平洋的往返

查看回應標頭 x-vercel-id 後發現，函式是在美國東部區域（iad1）執行的。而另一方面，資料庫（Supabase）位於東京。也就是說，每次查詢都會在日本與美國之間往返一次。

標頭看起來大致像這樣（示意）。

x-vercel-id: hnd1::iad1   ← 接收端在東京(hnd1)，但實際執行在美國(iad1)

只要有多次查詢，就會每次都橫跨太平洋往返，延遲便會不斷累積。

原因二：查詢採用序列等待

另外還有一個問題：首頁畫面在取得多項統計資料時，是採用**序列（一個接一個依序）**的方式進行的。往返所產生的延遲，就這樣按照次數原封不動地累加了起來。

解決方案

將執行區域固定在東京

我們在 vercel.json 中新增了區域設定，讓函式在東京（hnd1）執行。

{ "regions": ["hnd1"] }

如此一來，x-vercel-id 便會顯示為 hnd1::hnd1，函式與資料庫都位於東京，往返造成的延遲便得以消除。

查詢並行化

我們將原本以序列方式等待的統計資料取得改為使用 Promise.all 並行處理，同時也將重複的取得動作整合為一個。

結果

根據內部實測，首頁畫面的顯示時間從數秒縮短到約 0.2 秒左右。重點在於，我們並非依賴快取，而是讓處理本身變快。因此顯示的資料始終保持最新狀態。

學到的經驗

• 當出現「查詢明明很快，畫面卻很慢」的情況時，不要只懷疑資料庫的速度，也要懷疑函式與資料庫之間的物理距離（區域）。
• x-vercel-id 是確認實際執行區域時，一個簡便又強大的線索。
• 在往返成本較高的環境中，序列式的等待會造成致命影響。並行化能帶來很大的效果。

總結

體感延遲的真正原因，其實是美國與東京之間的往返。透過固定執行區域與並行化這兩項對策，我們在完全不依賴快取的情況下，大幅改善了體感速度。如果你也覺得 SSR 或儀表板速度很慢，不妨先確認一下執行區域與資料庫的位置關係。