边缘计算不只是 CDN 换了个名字，我用 Cloudflare Workers 把首屏时间从 2.3s 降到了 0.8s

边缘计算不只是 CDN 换了个名字，我用 Cloudflare Workers 把首屏时间从 2.3s 降到了 0.8s

导语

如果你还在把「边缘计算」理解为 CDN 换了个新马甲，那你可能错过了 2026 年前端性能优化最大的一波红利。传统 CDN 只能缓存静态文件，可你的页面 80% 以上的内容是动态的——用户信息、个性化推荐、实时数据——这些东西根本缓不住，每次都要回源。边缘节点近几年悄悄地进化了：它们不仅能存文件，还能跑代码了。Cloudflare Workers、Vercel Edge Functions、AWS Lambda@Edge 这些平台，让 JS 代码跑在全球 300+ 个节点上，离用户只有几毫秒的距离。我拿自己的工具站做了改造实测，首屏时间从 2.3s 砍到了 0.8s，核心逻辑就四行代码。

SSR 和 CDN 的「双输」困局

先看一个典型的 H5 页面请求链路：

用户 → DNS → CDN 边缘节点 → (缓存未命中) → 回源服务器 → 数据库 → HTML 返回

整条链路上最要命的是两件事：

1. CDN 缓存不住动态内容。 你可以在 CDN 上缓存 logo、CSS、JS，但页面上那个「Hi，王老师，您有 3 条未读消息」是动态的，CDN 帮不了你。

2. SSR 虽然有动态数据，但白屏时间依然长。 用户离服务器越远，TTFB 就越长。Next.js 默认 SSR 架构实测，国际用户 TTFB 平均在 450ms 以上（斯坦福研究数据，来源：ACM 边缘计算研讨会 2023）。

所以你一直在 SSR 和 CSR+CDN 之间选——要动态数据就要忍受回源延迟，要速度就只能做纯静态。

这个困局的本质是：你只能在「让谁渲染」这件事上二选一。

Edge Functions：在离用户最近的 CDN 节点上跑代码

Edge Functions 打破了上面那个困局。它的核心能力是：在 CDN 节点上执行 JS 代码。

对比一下就清楚了：

关键数字：Cloudflare Workers 冷启动时间不到 5ms，全球 330+ 边缘节点。Vercel Edge Functions 同样基于 Edge Runtime，TTFB 比传统 Serverless 函数平均快 3-5 倍。

实战：用 Cloudflare Workers 做边缘渲染，首屏减少 1.5s

我改造的是一个国际化工具站，面向全球用户，用户分布在北美、欧洲和亚太。原来用的架构是 Next.js SSR + 默认 CDN。

第一步：用 HTMLRewriter 在边缘注入动态内容

传统方案在客户端请求语言包，至少增加 1-3 个额外请求。用 Cloudflare Workers 的 HTMLRewriter API，在边缘实时处理 HTML：

// workers/index.js
export default {
  async fetch(request) {
    const response = await fetch(request)

    // 从请求中获取用户地理位置和语言偏好
    const lang = request.headers.get('Accept-Language')?.split(',')[0] || 'en'

    // 在边缘节点加载语言包（预缓存的数据）
    const i18nData = await getI18nData(lang)

    return new HTMLRewriter()
      .on('html', {
        element(e) {
          e.setAttribute('lang', lang.split('-')[0])
        }
      })
      .on('script#i18n-inject', {
        element(e) {
          e.setInnerContent(`window.__I18N__ = ${JSON.stringify(i18nData)}`)
        }
      })
      .transform(response)
  }
}

效果： 客户端少发 1-3 个网络请求，语言包零等待，TTFB 几乎零增加（实测 <5ms 开销）。

第二步：边缘流式渲染（ESR）—— SSR 的进化版

边缘流式渲染方案的核心思路是分两阶段返回：

1. 先返回静态骨架。 边缘节点第一时间吐出 HTML 框架 + CSS + JS

2. 流式注入动态内容。 边缘节点同时向源站请求动态数据，拿到后以流式方式追加

async function handleESR(request) {
  // 1. 先获取缓存的静态 HTML
  const cachedHtml = await STATIC_CACHE.get('page-shell')

  // 2. 创建流式响应
  const { readable, writable } = new TransformStream()
  const writer = writable.getWriter()
  const encoder = new TextEncoder()

  // 3. 立即写入静态骨架
  writer.write(encoder.encode(cachedHtml))

  // 4. 并行请求动态数据
  const [userData, notifications] = await Promise.all([
    fetchUserData(request),
    fetchNotifications(request)
  ])

  // 5. 流式追加动态内容到 HTML 尾部
  writer.write(encoder.encode(`<script>window.__DATA__=${JSON.stringify({ userData, notifications })}</script>`))
  writer.close()

  return new Response(readable, {
    headers: { 'Content-Type': 'text/html' }
  })
}

这个方案彻底打破了「动态 vs 速度」的二选一困局：

• 用户看到首屏骨架的时间 = CDN 最近节点返回静态内容的时间 ≈ 30-80ms
• 动态数据在后台并行拉取，慢也只有源站到边缘节点的那一跳

根据阿里云测试数据，ESR 方案在限速网络环境下，首屏时间较传统 SSR 缩短 30% 以上。

第三步：智能路由 + 边缘缓存

Edge Functions 还有一个被低估的能力：请求级的路由和缓存控制。

// 智能路由：根据请求特征分发到不同后端
async function smartRoute(request) {
  const url = new URL(request.url)
  const country = request.cf?.country || 'US'

  // 非个性化内容，交给 CDN 缓存
  if (url.pathname.startsWith('/_next/static')) {
    return fetch(request)  // 直接走 CDN，不经过 Worker
  }

  // 个性化 API，由 Workers 处理后返回
  if (url.pathname.startsWith('/api/personalized')) {
    const cacheKey = `personalized:${country}:${url.search}`
    const cached = await caches.default.match(cacheKey)
    if (cached) return cached

    const response = await fetchAndPersonalize(request, country)
    // 缓存 5 分钟
    const cloned = response.clone()
    caches.default.put(cacheKey, cloned, { ttl: 300 })
    return response
  }

  // 默认：实时页面，使用 ESR
  return handleESR(request)
}

这个策略的优化效果可以在 Lighthouse 报告中直接量化：

数据来源：我的工具站分别在改造前后使用 Lighthouse CI + WebPageTest 在 5 个地理区域各跑了 10 次取中位数。

不止 Cloudflare：主流 Edge Functions 平台横向对比

如果你是 Next.js 用户，Vercel Edge Functions 是最无缝的选择——只需在 API 路由或页面导出 runtime: 'edge'：

// app/api/edge/route.ts
export const runtime = 'edge'

export async function GET(request: Request) {
  const country = request.geo?.country || 'unknown'
  const ip = request.headers.get('x-forwarded-for')

  return Response.json({
    message: `Hello from ${country}`,
    timestamp: Date.now(),
    server: 'edge'
  })
}

如果是独立项目或需要最大覆盖范围，Cloudflare Workers 的全球节点数和冷启动速度目前仍是冠军。

什么时候你应该「上边缘」？

边缘计算不是银弹。它最适合同时满足以下 3 个条件的场景：

1. 你的页面有大量动态/个性化内容（不是纯文档站）

2. 用户分布在全球或全国多地（单机房用户用边缘加速收益边际递减）

3. 首屏体验是核心指标（电商、内容平台、工具站）

如果你只做国内业务，可以考虑腾讯云 EdgeOne 这类有国内节点的边缘计算平台，效果同样显著。

收尾

边缘计算对前端的价值，远不止「换个 CDN」。它真正做到了 「把代码部署到离用户最近的地方」——不只是一个基础设施概念，而是你能立刻上手的前端优化手段。今天下午你就可以做的事：在你的 Next.js 项目里加一个 Edge API Route，或者用 Cloudflare Workers 给你的静态站加点动态内容，跑一次 Lighthouse，看看数字掉下来多少。数据不会骗你。