Cloudflare Pages 的 SSR 相对于原生 Cloudflare Workers 会有一些额外的开销，主要是由于 Pages 需要额外的请求路由和文件管理。但整体损耗并不大，影响主要体现在 冷启动时间 和 CPU 执行时间限制。
Cloudflare Pages SSR vs. 原生 Workers 性能对比
| 指标 | Cloudflare Pages (SSR) | Cloudflare Workers (原生) |
|---|---|---|
| 冷启动时间 | 高一点（~10-50ms） | 几乎无冷启动（~1ms） |
| 执行时间限制 | 50ms CPU 时间 | 50ms CPU 时间 |
| 请求延迟 | 稍高（内部路由 & 资源管理） | 更低（直接执行） |
| 文件访问 | Pages 需要管理静态资源 | Workers KV / R2 访问更快 |
| 适合场景 | 全栈框架（Next.js, Nuxt, Remix） | API、边缘计算、无服务器应用 |
1. 冷启动
- 原生 Cloudflare Workers 几乎无冷启动，请求可以在 1-5ms 内处理。
- Cloudflare Pages 需要进行 额外的 Pages 资源加载 ，冷启动可能增加 10-50ms。
2. CPU 时间限制
- Cloudflare Pages 的 SSR 仍然受 50ms CPU 时间限制 约束，与 Workers 一样。
- 如果 SSR 逻辑复杂（如数据库查询、计算密集型任务），可能会达到 CPU 限制，导致执行超时。
3. 额外的 HTTP 请求损耗
- Cloudflare Pages 需要解析
functions/目录中的 SSR 代码，并转发到 Cloudflare Functions 执行。 - 这比原生 Workers 直接运行代码 多了一步请求解析 ，可能会增加 几毫秒的延迟。
实际性能测试
在 Cloudflare Pages 上使用 Next.js (App Router) 进行简单的 SSR 渲染：
-
静态渲染（SSG 页面） ： ~3-10ms
-
服务器端渲染（SSR 页面） ：
- 冷启动请求 ：50-100ms
- 热请求（已启动实例） ：10-30ms
-
API 请求（Cloudflare Functions 处理） ：5-20ms
相比之下，原生 Cloudflare Workers：
- 大多数请求在 1-5ms 内完成。
- API 响应更快，因为不需要额外的 Pages 处理流程。
如何优化 Cloudflare Pages SSR 性能
如果你在 Cloudflare Pages 上运行 SSR 框架，可以尝试以下优化：
-
减少 SSR 逻辑复杂度
- 让页面尽可能使用 静态生成（SSG）或增量静态再生成（ISR） ，减少 SSR 计算量。
- 复杂计算可以改为 API 请求（如 Edge Functions 或 KV 存储）。
-
使用 Edge Caching
-
结合 Cloudflare Cache-Control 头，将 SSR 页面缓存到 Edge，减少不必要的 SSR 请求。
-
例如：
arduinosh 复制编辑 Cache-Control: public, max-age=600, s-maxage=600
-
-
避免冷启动影响
-
通过 定期 ping 服务器 保持 Cloudflare Functions 活跃，减少冷启动。
-
例如：
arduinosh 复制编辑 curl https://your-cloudflare-pages-url.com/keepalive
-
结论
- 如果追求极致性能，原生 Cloudflare Workers 更快，特别是 API 计算或边缘计算应用。
- Cloudflare Pages SSR 有额外的延迟（冷启动 & 资源管理） ，但对于 Next.js、Nuxt 等全栈框架来说，它提供了更好的开发体验。
- 如果 SSR 计算复杂，可以考虑结合 Edge Caching 或直接使用 Workers 进行 API 计算。
➡ 适合你的选择：
- 如果你的应用主要是 SSR 页面（Next.js, Nuxt） → Cloudflare Pages
- 如果你的应用主要是 API、计算密集任务 → Cloudflare Workers