将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或仪表盘变慢了，不妨先确认一下函数的执行区域与数据库所在位置的关系。