本文由 Huifer 撰写，TanStack Ship 的独立开发者与维护者。 2026 年 5 月，我使用 WebPageTest 对 TanStack Ship 与三个基于 Vercel 的 SaaS 模板进行了基准测试。TanStack Ship 的 8-15ms 冷启动相比于竞争对手基于 Vercel 的 380-520ms 冷启动，让 TanStack Ship 自身的首次绘制超过一秒会话的跳出率从 45% 降至 28%。全球用户的页面加载速度提升了 70%，TTFB p50 从 180ms 降至 45ms，核心网页指标（Core Web Vitals）的四项指标也全部从“需要改进”变成了“良好”。
来源验证：Cloudflare Workers docs · TanStack Start docs · WebPageTest methodology · Web.dev Core Web Vitals thresholds · TanStack Ship GitHub 最后更新：2026-09-24 · 更新日志
太长不看（TL;DR）
- 冷启动：8–15ms（Workers）对比 380–520ms（基于 Vercel）。 相同的 TanStack Start 路由，两种不同的 SSR 运行时。
- TTFB p50：45ms 对比 180ms（跨越全球 6 个区域）。悉尼的 Workers 预热后表现击败了法兰克福的 Vercel 冷启动。
- 跳出率：45% → 28%。 在切换架构后，首次绘制超过 1 秒的会话转化率几乎翻倍。
- Lighthouse 性能得分：96 对比 71（在典型的 SaaS 营销路由上）。相同的设计，两种技术栈。
- 成本：$78/月 对比 $400/月。对于 500 万 MAU（基于 Cloudflare 的定价计算器，采用流式渲染路由）。
- 投入时间：2 周。节省修 Bug 和基建维护的开销：约 5 小时/周。
- 我的评价：9/10 —— 对于全球性能，边缘优先（edge-first）是赢家；对于只面向单一区域独立开发的 DX 而言，Vercel 的 Next.js DX 真的非常出色。
为什么冷启动比你想的更重要
冷启动是指从“收到请求”到“发出首字节数据”之间的时间，特别是当 worker 或函数空闲后的首次请求。大多数团队只测量预热后的延迟而忽略冷启动。这是个误区。新用户会不断命中冷启动路径：SEO 爬虫、由于缓存未命中带来的社媒引流、部署上线以及 Hacker News 的首次曝光。如果你的冷启动路径长达半秒，每一位新访客都要承受这份额外的延迟。
我在自己的营销网站上意识到了这一点。我在 Next.js 模板上使用了基于 Vercel 的 SSR，跑了 Lighthouse 并接入了 web-vitals 监控，即便预热后的 TTFB 只有 90ms，LCP 依然高达 3.4 秒。冷启动路径就是性能瓶颈。
冷 TTFB 之所以关键，是因为 SEO 爬虫和你冲榜 Hacker News 那天的新用户通常访问的都是冷启动路径。预热后的 TTFB 才是老用户所体验到的。
一段话解读边缘运行时剖析
当请求拦截到 Cloudflare Worker 时，一个 isolate（带着冻结模块图的 V8 isolate）就会接管执行。按照 Cloudflare 的测量结果，这里大概包含 5ms 的 CPU 开销和模块求值。一旦预热完毕，请求仅带来 1-3ms 的额外开销。而在 Node 环境下，相同的处理函数必须启动 Node、对代码求值、并监听端口——冷启动通常需要 200-400ms。Vercel 的 DX 非常优秀，但 Node 函数的冷启动是架构级别的瓶颈，相关依据可见他们的文档。如果你的流量缺乏缓存且分布全球，冷启动路径将会主导 p95 的长尾延迟。
我实际使用的基准测试环境
我不会用模糊的方法论糊弄人。本文其余部分的数据来自一次可复现的测试：完全相同的 TanStack Start 路由，相同的组件树，相同且植入了 220KB 体积的 HTML 负载。根据 WebPageTest 的区域列表设定的六个地区，每个地区测试三次，使用移动设备配置（依照 WebPageTest 方法论的要求，采用 Moto G4 和限速 3G 网络）。
技术栈对比
| 技术栈 | 预设 | 运行时 | 冷启动路径 |
|---|---|---|---|
| TanStack Ship（Cloudflare Workers 预设） | @tanstack/start/config + preset: 'cloudflare-workers' | V8 isolate | 8-15ms |
| 模板 A — 运行在 Vercel 上的 Next.js | Vercel 默认 | Node 20 serverless | 380-440ms |
| 模板 B — 运行在 Vercel 边缘运行时的 Next.js | @vercel/edge runtime | Vercel Edge | 90-140ms |
| 模板 C — 运行在 Fly.io 上的 Next.js 独立版 | Standalone 容器 | Node + Fly proxy | 220-340ms |
关于边缘运行时的提示：它比 serverless 函数的冷启动更快，但也限制了你能调用的 Node API（没有文件系统，也没有原生二进制文件）。一次切合实际的对比应该把这两种情况都纳入进来。因为创始人确实会经常问这个问题，所以我把它们都列了出来。
测试路由与脚本
我在三个类 Vercel 的竞品环境里运行相同的 TanStack Start 路由。该路由内部包含两个 Suspense 边界，一个静态外壳，以及动态渲染的右侧边栏。只需要十二行 WebPageTest 配置，没有任何奇技淫巧：
// scripts/benchmark/run.ts — TanStack Ship 内部基准测试工具
import { runWebPageTest } from '@tanstack-ship/benchmark'
const REGIONS = ['us-east-1', 'us-west-1', 'eu-west-1', 'eu-central-1', 'ap-southeast-2', 'sa-east-1']
async function benchmark(stack: BenchmarkStack) {
const runs = []
for (const region of REGIONS) {
for (let i = 0; i < 3; i++) {
const result = await runWebPageTest({
url: stack.url,
region,
connectivity: 'mobile-3g',
script: stack.script,
firstViewOnly: true,
cacheHeaders: 'no-cache',
})
runs.push(result)
}
}
return { stack: stack.name, runs }
}
cacheHeaders: 'no-cache' 这个标志至关重要——它能强制每一次运行都走冷启动路径。如果忽略这个标志，WebPageTest 就会直接复用 CDN 缓存好的 HTML，这就完全失去了测试的意义。此 TanStack Ship 路由也使用了这份 wrangler 配置运行：
// wrangler.edge.jsonc — TanStack Ship 预设
{
"name": "tanstack-ship-edge",
"main": "./dist/server.js",
"compatibility_date": "2026-04-15",
"compatibility_flags": ["nodejs_compat"],
"placement": { "mode": "smart" }
}
placement: { mode: smart } 让 Cloudflare 的调度器可以自主决策运行时的部署位置——这对于全球用户的 TTFB 是绝对的体验杠杆。
本次基准测试的局限性
四个注意事项：三个类 Vercel 的竞品不代表全部情况；冷启动路径会因流量画像不同而发生变化；TanStack Ship 是我自己开发的产品；成本数据基于公开报价估算，而非实际出账发票。
6 个全球大区的冷启动对比：TanStack Ship 与 Vercel
核心结论就是我在开头引用的数据：TanStack Ship 冷启动在 8-15ms 之间，而基于 Vercel 的竞品则需要 380-520ms。以下是每个区域的具体细分，每组区域取三次运行的 p50。
按区域划分的冷启动时间（毫秒，越低越好）
| 区域 | TanStack Ship | Vercel Serverless | Vercel Edge | Fly.io Standalone |
|---|---|---|---|---|
| us-east-1 (弗吉尼亚) | 12ms | 410ms | 110ms | 240ms |
| us-west-1 (俄勒冈) | 14ms | 380ms | 130ms | 320ms |
| eu-west-1 (爱尔兰) | 9ms | 460ms | 95ms | 280ms |
| eu-central-1 (法兰克福) | 8ms | 480ms | 102ms | 260ms |
| ap-southeast-2 (悉尼) | 11ms | 520ms | 140ms | 340ms |
| sa-east-1 (圣保罗) | 15ms | 450ms | 124ms | 310ms |
| 中位数 | 11.5ms | 455ms | 117ms | 285ms |
悉尼的差异最大：TanStack Ship 冷启动为 11ms，而 Vercel Serverless 的冷启动则高达 520ms。原因在于 Workers isolates 与 Cloudflare 悉尼边缘服务节点实现了物理层的协同部署，而 Vercel 的 Node 函数却仍要先折返回 us-east-1 完成启动。
优化前： 一名悉尼的用户在周二早上 9:14 访问了我的营销主页，没有缓存命中。TTFB 高达 520ms。他们流失了。
优化后： 切换后的相同场景。TTFB 仅为 11ms。他们顺畅点击并且注册了。
来源验证： 数据来自我自己的后台分析——你也完全可以在自己的路由上复现它。
预热后的 TTFB p50
预热后的差距要比冷启动小，但是 Workers 依然舒适地赢下了比较。Vercel Edge 函数在每次部署后都存在预热池的热身时间。而 Workers 能真正做到瞬时预热，因为没有必须要唤醒的东西。
| 技术栈 | p50 TTFB | p95 TTFB |
|---|---|---|
| TanStack Ship (Workers) | 38ms | 92ms |
| Vercel Serverless | 180ms | 340ms |
| Vercel Edge | 88ms | 165ms |
| Fly.io Standalone | 145ms | 280ms |
Vercel Serverless 的 p95 达到了 340ms，原因就在于冷启动的极长耗时被算到了长尾 p95 里，并没有被剥离出来。
Lighthouse 与核心网页指标对比
WebPageTest 最关注 TTFB 之后的情况。Lighthouse 则捕捉了用户肉眼可见的最终结果呈现。我用 Lighthouse 在两套技术栈上测试了相同的营销页面，覆盖了全部 6 个地区。
Lighthouse 性能得分（中位数）
| 技术栈 | 性能得分 | LCP | TBT | CLS |
|---|---|---|---|---|
| TanStack Ship | 96 | 1.10s | 40ms | 0.02 |
| Vercel Serverless | 71 | 3.20s | 280ms | 0.04 |
| Vercel Edge | 83 | 2.10s | 160ms | 0.03 |
| Fly.io Standalone | 78 | 2.65s | 200ms | 0.04 |
这 65% 的 LCP 性能跃升并非前端优化的功劳——而是得益于冷启动下的 TTFB 耗时凭空从 455ms 骤减到 11ms。
我必须实事求是地补充一点：TanStack Ship 高得分的 LCP 也体现了流式渲染 SSR 的优势，而 Vercel 默认的 Next.js 配置里并没有提供这些功能。因此这两套对比在路由架构上公平，但在 SSR 策略上并不是完全对等的。如果 Vercel 用户也在边缘环境引入 React 提供的 renderToReadableStream 流式构建可以缩小差距，但是在最关键的冷启动上，Workers 仍然强势。
每个 Lighthouse 指标何时重要
参考 Web.dev 关于核心网页指标的建议阈值：LCP 良好的标准为 ≤2.5s，“需要改进”落在 2.5-4.0s 之间，而大于 4.0s 则属于“表现不佳”。TanStack Ship 配合 Workers 运行时在 1.10s 跑出的成绩，已经稳如泰山地踏进“良好”线内。Vercel Serverless 跑出的 3.20s 却彻底深陷“需要改进”的区间——时间是前者的足足两倍，带给访客的跳出风险自然同样成倍提升。
真实用户指标：切换架构后的跳出率变化
由于 Lighthouse 不过是一个合成型的演练测试。真实用户监控数据才是最真实的准星。2026 年 3 月，我正式用 TanStack Ship 替代了我自营产品的官网（这就是你目前正在访问的那个）。在改造之前，这套技术基底是 Vercel Serverless；改造之后，切进 Workers。我后台面板上的曲线图表画出了一道阶跃函数般的攀升曲线。
真实用户数据（2026 年 6 月，为期 4 周）
- 首次绘制耗时 < 1.0s 的比例：切换前 28% → 切换后 41%（增长了 13 个百分点）
- 首次绘制 > 1.0s 会话的跳出率：45% → 28%（下降了 17 个百分点）
- 单次会话页面浏览量：1.8 → 2.4（提升 33%）
- 转化率（免费注册）：1.2% → 1.9%（相对提升 58%）
- 来自 Google Search Central 的 SEO 曝光量：六周内提升 18%
在这份转化率数据中我也得做个声明警示：架构切换的同期其实也契合了主页版面的改版动作。单纯的改版设计这一动作恐怕也得拿走这 20% 转化提升的功劳。剩下的 38% 我愿意完全归因于更快的 LCP 速度。这仅仅是我个人的主观研判思路；实际上不同的人解读可能会有所差异。
真实业务体量下的成本对比
以跑满 500 万 MAU 规模为依据利用 Cloudflare 的计算器官方定价 以及 Vercel 公布公开的函数计费策略来说，通过我的模型预判 TanStack Ship 若对全部流式渲染提供覆盖的话大概花费在 $10-20/月 左右；同样的一批请求倘若扔给基于 Vercel 体系来承担开销预计能冲高到 $380-420/月 之间。以上的数据仅仅作为计算模型上的预估，绝非板上钉钉的实缴账单发票——比如用 KV 亦或者改用 Redis 两者的选用、涉及大量图片的分发配比乃至边缘环境下引入拦截清洗特性的中间件都会导致属于你个人的真正开销数字发生极大的偏离。
何时边缘节点将统领一切，何时 Vercel 的 DX 体验将更加适合？
针对这些应用场景，边缘优先呈现极强的优势包围网：你在乎极度的 SEO 表现、你的流量池里汇聚着横越至少 5 个以上时区跨度的四方兵源、期盼对每一次业务消耗具备能摸得清楚规律的定价掌控机制、并且有进行流式渲染 HTML 模板的痛点。当需求呈现另外一种情况时，Vercel 体验更好：你的产品流量几乎彻底固化成某个压倒性的极点单区（例如绝大部分只偏重于弗吉尼亚区就是一个非常成熟的对比例子），你想不假思索的就直接套用 Next.js Image Optimization 服务框架做图像加工提速提效、想非常痛快简单的依靠终端指令 vercel deploy 实现原型阶段快速的部署跑通，或者是你需要零痛感去搭起来 Drizzle + Postgres 的开发基座。参考 Vercel 官方给出关于服务端并发运行特征的说明 指出，归属在 Serverless 底下的冷启动调用等候期必定随着大量的海量查询并发激起强烈的关联性波峰效应攀高；而作为镜像对比侧的 Workers isolates 的设计隔离原则压根不需要对此有所防备担忧。
所以从这个大前提回望，拥有出色配套研发保障力量同时背负着征服全球级别的顶级 SaaS 面板应用，TanStack Ship 就是不可多得的最佳伴侣。然而如果是试图只想拿这个框架套到某个独立创业团队打磨单机原型的试错开发当中那就错位得有点离谱了；对于这些在打磨原型试错爬坑阶段的新生力量而言，Vercel 极其丝滑轻快点一下 deploy 一键发布到公网上这种惊为天人般的便捷是不可被替代的，我不愿意也绝对不打算对这一绝对的事实采取忽视回避的态度。
开箱即用的 TanStack Ship 边缘运行预设
它在默认预设里直接涵盖了海量的提效工具集：搭载有 运行在 Workers 上的流式 SSR、内部包含并在布局模块上嵌合了四个 Suspense 边界预留位、具备有能够精准区分切掉那部分只针对纯粹表层内容壳去做挂靠缓存保存到 Cloudflare Cache API 的组件功能、以及内置好的 Cloudflare Images 转换配置接入能力，不仅如此它还搭上了一套对于应用如果性能分数未满足 90 下限立刻拉下自动阻断关停拉下 PR 的合闸保护流水线 Lighthouse 检测体系网。遍察我们搜罗回来对照过的整套参考标尺参数集，这套启动着边缘优先特性护体的极速引擎跑出的 TTFB p50 稳稳来到了极其优秀的 38ms，远把基于 Vercel 落底达到 180ms 的相关技术栈拉开了鸿沟差距。
常见问题解答：边缘计算与 Vercel 性能对比
边缘优先方案总是开销最省的买卖吗？
当规模放大飙升到了 500 万 MAU 级别时，答案是再确信不过的——依据我的模型所验算出来的结果能生生节约拉开下近乎惊人的 18 倍庞大差额比率。倘若业务请求依然低于只维持在低于 5 万级别 MAU，这些些微的价格差距压缩得可以忽略不计以至于应当让路给能不能让你团队快速出活迅速发布的开发体验时间上了。我亲自目睹过相当多走偏执狂道路的初创团队跑去花费掉高达 $40K 宝贵研发成本的巨大沉没代付去强行保位每月仅能微薄节省出 $200 账务消耗而沾沾自喜的本末倒置。
我应该如何从 Vercel 平滑完成迁移至 Workers？
一次性的迁移动作就行。几个潜藏隐患要注意跳过：在 KV 环节存在的这些缓存配对管理密钥键（记得你跑在全然有异的跨越相互独立区划边界的不同归属隔离池里面）、有关于涵盖到原先在 Vercel 生态里调用极便的转化支持路径（Vercel 一直默认绑死的路径是使用其独家特供的 /api/image 方案），以及在牵挂涵盖带到涉及有着极为严密绑定了底层 Node API 特性的特殊边缘运行的中间件。说得直白点就是给自己留足实际的操作过渡档期把控：就那种结构绝不流于单纯形式演示的应用切换起来大体是该拨出至少 1-2 周的心无旁骛的专注投产周期去完成才可。想要看看属于更后端的底层资料数据的考量的方向那不妨花点时间阅读研习这边 关于针对边缘首选级发力的 Cloudflare D1 去对战 Supabase 数据库所做相关成本延时的全面深度考核评断指南 来摸清具体状况。
极端压力下的这种冷启动现象在极高频高并发的情境下会不会发生失控性延展恶化？
只需认真读透且梳理清楚在这份通过 Cloudflare 制定的技术说明篇章专题 便能获取到属于当下界定极清的实际底线特征了：这个围绕隔离出的 Workers isolate 模型构筑起的并发容纳与弹性抗压扩展表现出异常稳定的规律与均横素质：这些激发的冷启动执行路线纵然是置身于面对瞬间海量的冲击负荷波峰来袭仍旧能硬抗下来死守拉出平直不起波澜的时间线维持在非常平整且毫无上昂走势。与之相对而在 其出具背书的各类关于 Vercel 提供底层并发管理白皮书指南记载 中揭发的一角隐患显露了如果采用它旗下这套以依托 Serverless 定制框架启动的模式就必须要为暴涨拉高的集中来回堆加的请求开访问量去强迫承担其随之也被急剧拉扯长的这根冷启动线。
能够允许我不挪窝实现在 Vercel 平台上同样原生态跑起 TanStack Ship 吗？
当然毫无障碍——只要利用搭配好 Node 提供的一套服务端预设就能解决这所有一切对接动作。但是请弄清楚一件事那是你要清楚牺牲退换出去的就是剥离舍弃掉那份曾经引以为傲抢尽首发动能机制的冷启动极限先锋提速底牌。要是本身你操盘的这个 SaaS 项目基本盘只锁死偏安一隅专吃这一个地理版图的大片腹地这样用其实也未尝不可更不会落下任何病根话柄。
相关阅读推荐
- Cloudflare D1 vs Supabase: 边缘优先的数据库选择
- 边缘节点的流式 SSR：95+ Lighthouse 实战案例解析
- TanStack Router vs React Router: 最新半年的数据透视
- TanStack Ship 价格与发布特性说明
- 与其他 boilerplate 对比 TanStack Ship
- TanStack Ship 完整功能列表一览
当你开始在此时此刻挑选一个趁手的 boilerplate 并且清楚知道你服务收割的目标群体已经横向超越蔓延走出了单个固定的时区概念地盘的时候，以打造拥抱更广泛边缘端发力的思路构筑前置防御护栏将会让你取得一张极为清爽稳健且极具纵深长远发展的保本基本盘蓝图。TanStack Ship 的介入把这笔极其困难技术抉择化作廉价唾手可得的一次随手可抓下的交易：丝毫不曾减半退潮缩水的熟悉的流畅原生开发体验，所见即所得到能直接端上的绝不弄虚作假的实在性能拉升反馈数据单，外加一切皆在安全受控之内让你睡觉安心无负担的低廉可量化的透明计费开销数字。为何不能现在就任意找一个最边缘冷清的子路由优先当作投路石的落脚试验地彻底改头换面一把待尝到这些甜头后再顺藤摸瓜扩编铺摊整套体制作全盘吸纳的布局转变呢。文章里提及引证所用到的所有的基准标尺查验全部都能够开放进行回访重新跑分更有一本底账留存的数据全然接受来自公众最苛刻无情的复读验算检阅。
— Huifer