github-pages - 如何使用 Cloudflare Workers 优化静态网站的 TTFB？

Question

我有一个托管在 GitHub Pages 上的网站，完全静态 HTML，加载速度相当快。我一直在尝试缩短 TTFB 时间(以及 FCP、LCP 和满载时间)。
现在尝试专注于 TTFB，我做了几次尝试。

1. 在仅 DNS 模式下使用 Cloudflare，我获得了一致的 TTFB 99% 低于 30 毫秒。
2. 在代理模式下使用 Cloudflare，页面规则为“缓存 Everything”，TTFB 始终高于 100ms。

然后我尝试使用 Cloudflare Workers，想法很简单:

• a.将当前网站内容获取到工作线程中。
• b.缓存内容
• c.提供缓存内容

令人惊讶的是，我得到的时间没有超过 80 毫秒，尽管我预计 TTFB 比我的第一次试验(仅 DNS 模式)要少得多，但平均而言，TTFB 介于 100 毫秒到 150 毫秒之间；我正在测试 Worker 的 url (random-name.organization-name.workers.dev)。 我怀疑我的工作代码有问题，这是我到目前为止所尝试的(主要来自文档)

const url = "https://domain.extension"
async function gatherResponse(response) {
  const { headers } = response
  return await response.text()
}
async function handleRequest() {
  const init = {
    headers: {
      "content-type": "text/html;charset=UTF-8",
    },
    cf: {
      cacheTtl: 50000,
      cacheEverything: true,
    },
  }
  const response = await fetch(url, init)
  const results = await gatherResponse(response)
  return new Response(results, init)
}
addEventListener("fetch", event => {
  return event.respondWith(handleRequest())
})

是否有一种方法可以缓存所有内容并让工作人员比仅 DNS 选项更快地提供服务？我尝试升级我的 Cloudflare 计划，并且还得到了一名付费员工，希望能再节省几毫秒，但毫无希望。

Answer 1

当涉及到您所描述的基本缓存时，Workers 不会比 Cloudflare 的内置 HTTP 缓存选项提供任何优势。如果您已经设置页面规则来指定“缓存所有内容”和“边缘缓存 TTL 50000”，那么您编写的 Worker 代码将不会产生任何额外效果。当您拥有单独使用页面规则无法实现的更复杂的逻辑时，工作线程非常有用。

(事实上，您发布的特定代码实际上会使 TTFB 变得更糟，因为它在返回响应之前确实 await response.text() ——这迫使 Worker 等待整个响应响应正文在任何响应发送到客户端之前到达 Cloudflare。通常，Workers 会在响应内容到达时流式传输。)

如果您发现您的网站在仅 DNS 模式下比在代理模式下更快，这很可能意味着您测量速度的位置(例如您的家庭互联网)恰好比您的源服务器更接近是 Cloudflare。这很不寻常，但也有可能发生。为了更真实地了解性能差异，您需要从世界各地的多个位置进行测量。请注意，由于 GitHub 本身已经使用缓存 CDN 来服务 Pages，因此您可能仍然会发现平均性能差异不是很大。