用户每次访问您的网页时，他们都是在发起竞赛，以尽可能快地接收内容。性能是影响访问者如何与您的网站交互的一个关键因素。一些人可能会认为在全球范围内传输内容会导致显著的延迟，但实际上，网络传输速度已经接近其理论极限。为了更好地理解这一点，Cloudflare 上的数据可以在大约 76 毫秒内完成纽约到伦敦之间 11000 公里的往返——这比眨眼还要快。
然而，由于处理请求、响应和配置的复杂性，网页加载延迟仍然存在。除了推动连接建立、压缩、硬件和软件的进步，我们还打造了一种新方法，通过预测访问者如何与特定网页互动来减少页面加载延迟。
今天，我们非常高兴地与大家分享速度方面的最新飞跃： Speed Brain 。它依靠 Speculation Rules API 来预取用户下一个可能导航到的内容。 Speed Brain 的主要目标是在用户导航到网页之前将其下载到浏览器缓存中，以便在实际导航发生时页面几乎可以立即加载。
我们的初步方法使用一种保守模型，在用户开始触摸或点击事件时预取下一个页面的静态内容。到2024 年第四季度及 2025 年，我们将推出更积极的推测模型，例如推测性预渲染（不仅是在导航发生前获取页面，而是完全渲染它），以提供更快的体验。最终，Speed Brain 将学会如何消除静态网站的延迟，而且无需任何配置，并与浏览器协作，确保尽可能快地加载。
举例说明，想象一个销售服装的电商网站。利用我们全球请求日志的数据，我们可以高准确性地预测，典型访客在浏览父页面“男士 > 服装”时，很可能会点击“衬衫”。基于此，我们可以在顾客甚至还没有点击“衬衫”链接之前，就开始提供静态内容，例如图片。因此，当他们不可避免地点击时，页面会瞬间加载。我们的激进加载模型实施在最近的实验室测试中显示，最大内容绘制（LCP）的加载时间减少了多达75%。LCP 是加载和在浏览器中渲染最大可见元素（如图像、视频或文本块）所需的时间。
最棒的是什么？我们将立即向所有计划类型免费提供 Speed Brain。只需从仪表板或通过 API 为您的网站开启 Speed Brain 功能。这感觉就像变魔法一样，但在幕后，它需要大量巧妙的工程设计。
我们已经在所有免费域名上默认启用 Speed Brain，并且发现成功预取时 LCP 减少了 45%。 Pro、 Business 和 Enterprise 域需要手动启用 Speed Brain。如果您还没有这样做，我们强烈建议您通过仪表板启用真实用户测量(RUM) ，以便看到网页性能的新改善。作为额外的好处，您的域名启用 RUM 将帮助我们在不久的将来为您的网站提供改进和自定义的预取和预渲染规则。
在讨论 Speed Brain 如何帮助极速加载内容之前，我们需要退一步，回顾一下在浏览器上加载内容的复杂性。每次用户导航到您的网页时，都必须完成一系列请求和响应周期。
浏览器与服务器建立安全连接后，会发送 HTTP 请求以检索网页的基础文档。服务器处理请求，构建必要的 HTML 文档，并通过响应发送回浏览器。
浏览器收到一个 HTML 文档时，会立即开始解析内容。在此过程中，它可能会遇到对外部资源的引用，例如 CSS 文件、JavaScript、图像和字体。这些子资源对于正确渲染页面至关重要，因此浏览器会发出额外的 HTTP 请求来获取它们。但是，如果这些资源在浏览器的缓存中可用，则浏览器可在本地检索，从而显著降低网络延迟并缩短页面加载时间。
随着浏览器处理 HTML、CSS 和 JavaScript，渲染引擎开始在屏幕上显示内容。一旦页面的视觉元素显示出来，用户的互动——比如点击一个链接——会促使浏览器重新启动大部分这个过程，以获取下一页的新内容。这是每个浏览会话的典型工作流程：当用户导航时，浏览器不断获取并渲染新的或未缓存的资源，这会在新页面完全加载之前引入延迟。
以用户浏览上述购物网站为例。当购物者从主页转到网站的“男士”部分，再到“服装”部分，再到“衬衫”部分时，获取每个后续页面所花的时间会越来越多，可能导致购物者在完成交易之前就离开网站。
理想情况下，在每次点击这些链接时，如果浏览器中已经预取和预渲染对应页面，就可以消除大部分网络延迟的影响，让浏览器能够瞬间加载内容，从而提供更流畅的用户体验。
等等，这种说法我已经听过了（这与 Speed Brain 有何关系？）
我们知道您在想什么。我们一直进行预取。过去甚至出现过几次预测性预取的尝试。您以前已经听说过这些。现在和以前有什么不同呢？
没错，您是对的。多年来，开发人员和浏览器供应商一直在努力优化页面加载时间并增强用户的 Web 体验。人们已经开发了许多技术，涵盖互联网堆栈的各个层——从优化网络层连接，到在更靠近客户端的位置预加载应用的内容。
Web 预取是这样一种已经存在超过十年的技术。它基于这样的假设：某些子资源在不久的将来很可能会被需要，那么为什么不主动预取呢？这可以包括用户在浏览网站时可能需要的 HTML 页面、图像、样式表或脚本等任何内容。事实上，预测性执行的核心概念并不新鲜，因为它是一种在计算机科学的各个领域广泛应用的通用技术，多年来一直存在，CPU 中的分支预测就是一个典型例子。
在 Web 早期，出现了几种自定义预取解决方案来提高性能。例如，Google 在 2005 年推出了Google Web Accelerator ，这是一个旨在加快宽带用户浏览速度的客户端应用程序。虽然具有创新性，但由于隐私和兼容性问题，该项目持续时间很短（我们将在下文介绍 Speed Brain 的不同之处）。当时的预测式预取缺乏数据洞察和 API 支持来捕获用户操作，特别是那些处理删除或购买等敏感操作的操作。
传统上，预取是通过使用 <link rel="prefetch"> 属性作为资源提示之一来完成的。开发人员必须在每个页面上为他们希望浏览器预先获取并在内存中缓存的每个资源手动指定属性。这种手动工作不仅费时费力，而且开发人员往往不知道应该预取哪些资源，从而降低了特定提示的质量。
同样， Cloudflare自 2015 年以来就提供了 URL 预取功能。 Cloudflare 允许客户将静态资源列表预取到 CDN 缓存中，而非在浏览器缓存中预取。该功能允许在实际需要之前预取资源，通常是在空闲时间或网络条件良好时。然而， CDN 预取也存在类似的问题，因为客户必须手动决定哪些资源是对其拥有的每个页面进行预取的良好候选者。如果配置错误，静态链接预取可能会成为一个陷阱，导致网页加载时间反而变慢。
HTTP/2 的“服务器推送（server push）”是通过在客户端请求资源之前将资源推送到客户端来提高 Web 性能的另一种尝试。理论上，这样可以消除未来资产的额外往返需求，从而减少延迟。然而，这种以服务器为中心、独断专行地将资源“推送”到客户端的做法带来了重大挑战，这主要是因为缺乏有关浏览器中已缓存内容的上下文。这不仅浪费带宽，而且有可能由于渲染页面时浏览器获取的竞态条件而减慢关键资源（如基础 HTML 和 CSS）的交付速度。提议的缓存摘要解决方案本可以将客户端的缓存内容告知服务器，但其从未得到广泛实施，导致服务器只能盲目地推送资源。 2022 年 10 月， Google Chrome 取消了服务器推送支持， Firefox 于 2024 年 9 月跟进。
作为继任者， Early Hints 在 2017 年提出的，但直到 2022 年才被广泛采用，当时我们与浏览器和重要客户合作进行了部署。通过“提示”客户端要加载哪些资源，提供了一种更有效的替代方案，以便根据浏览器的需求更好地进行优先排序。具体来说，服务器会发送 103 Early Hints HTTP 状态码 ，以及一个浏览器应在准备主要响应时开始加载的关键页面资产列表。这使浏览器能够提前一步获取必要的资源，并避免在资源已经缓存的情况下进行冗余的预加载。尽管 Early Hints（暂时）还不适应用户行为或动态页面条件，但它的使用主要限于预加载特定资产而不是完整网页——特别服务器需要长时间“思考”以生成 HTML 的情况下。
随着 Web 的发展，能够处理复杂、动态用户交互的工具将变得越来越重要，以便在预测执行的性能提升与其对最终用户的潜在缺点之间取得平衡。多年来， Cloudflare 一直在提供基于性能的解决方案，例如 Argo Smart Routing 、 Smart Tiered Cache 和 Smart Placement ，这些解决方案会适应用户行为并努力在互联网上平衡速度和正确性决策。今天，我们向提供闪电般快速内容的灵活框架迈出了新的一步。
Speed Brain 提供了一种稳健的方法，根据我们服务器返回的规则集，直接在浏览器中实施预测性预取策略。通过吸取以往的经验教训，该解决方案将资源预测的责任转移给客户端，从而根据用户交互（例如将鼠标悬停在链接上）及其设备能力来实现更加动态和个性化的优化。浏览器不再无所事事地等待用户请求下一个网页，而是从用户与页面的互动中获取线索，在用户还未完成对链接的点击前就提前开始请求下一个网页。
幕后使这成为可能的是 Speculation Rules API ——这是 Google 在 Web 性能领域的一个新兴标准。启用 Cloudflare 的 Speed Brain 功能时，一个名为Speculation-Rules的 HTTP 标头将添加到网页响应中。此标头的值是一个 URL ，其中包含固定的规则配置。此配置指示浏览器启动预取请求，为将来的导航做准备。 Speed Brain 不会改善网站被访问的第一个页面的加载时间，但它可以改善同一网站上后续访问网页的加载时间。
这个想法似乎很简单，但预取会带来挑战，因为一些预取的内容可能永远不会被使用。随着 Speed Brain 的首个版本发布，我们设计了一种带有防护的解决方案，解决两个重要但独特的问题——过时预取配置和不正确的预取。我们为此初始版本选择的 Speculation Rules API 配置经过了精心设计，以平衡预取的安全性，同时保持规则对整个网站上的广泛适用性。
随着时间的推移，网站的变化不可避免，静态预取配置往往会过时，导致预取效率低下或效果不佳。对于 rel=prefetch 属性或静态 CDN 预取 URL 集之类的技术尤其如此，这些技术要求开发人员手动维护每个页面相关的可预取 URL 列表。大多数静态预取列表是基于开发人员的直觉，而不是实际用户的导航数据，这可能会错过重要的预取机会，或者在不必要的预取上浪费资源。
由于预取请求就像普通的请求一样，除了带有一个 `sec-purpose` HTTP 请求标头，因此它们会对客户端、网络和服务器产生相同的开销。然而，关键区别在于预取请求预见了用户行为，并且响应可能最终没有被使用，因此所有这些开销可能都被浪费了。因此，预取的准确性极其重要——也就是说，要最大化最终被用户查看的预取页面。不正确的预取可能导致效率低下和不必要的成本，例如缓存不被请求的资源，或浪费带宽和网络资源，这在按量收费的移动网络或低带宽环境中尤其严重。
在 Speed Brain 的初始版本中，我们设计了一种具备重要副作用防护的解决方案， 完全消除了过时预取配置的可能性， 并最小化不正确预取的风险。这种特定配置是通过利用文档规则以及 Speculation Rules API 中的 eagerness（紧迫性）设定来实现的。我们选择的配置看起来如下：
{
"prefetch": [{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*", "relative_to": "document" },
]
},
"eagerness": "conservative"
}]
}
Document Rules（文档规则），通过 "source": "document" 和配置中的 "where" 键表示，允许在整个网页上动态应用预取。这消除了为预取而需要的预定义静态 URL 列表。因此，我们消除了过时预取配置的问题，因为预取候选链接是基于活动页面结构确定的。
我们在 where 子句中使用 "relative_to": "document" ，指示浏览器将预取限制为相同站点的链接。这样做还有一个额外的好处，即我们的实现可以避免跨域预取，从而避免对用户的任何隐私问题，因为它不会在网络上跟踪用户。
Eagerness（紧迫性）控制浏览器预取内容的程度。有四种可能的设置：
immediate ：在页面加载时尽快使用——通常为浏览器一看到规则值，就开始预取下一页。
eager ：与上面的即时设置相同，但是预取触发器另外依赖于轻微的用户交互事件，例如将光标移向链接（即将推出）。
moderate ：将指针悬停在链接上超过 200 毫秒则预取（或在发生 pointerdown 事件时预取，前提是后者时间更短；以及在没有 hover 事件的移动设备上）。
conservative ：在链接上按下指针或触摸时进行预取。
Speed Brain 的初始版本利用 conservative 的紧迫性值来最大程度地降低不正确预取的风险（会导致非预期的资源浪费），同时使您的网站速度明显加快。虽然我们会失去更激进的紧迫性设置所带来的潜在性能改进，但我们选择了这种谨慎的方法来优先考虑用户的安全。展望未来，我们计划探索更动态的网站紧迫性设置，以便从更自由的设置中受益，我们还将扩展我们的规则以包含预渲染。
我们实施的另一项重要保护措施是只接受已经存储在我们 CDN 缓存中的静态内容的预取请求。如果内容不在缓存中，我们将拒绝预取请求。直接从我们的 CDN 缓存中检索内容以供预取请求，让我们不必担心缓存资格。这样做的理由很简单：如果一个页面不符合缓存条件，我们不希望它被预取到浏览器缓存中，因为这可能会导致意外后果和增加源服务器的负担。例如，预取一个注销页面可能会导致用户在实际完成操作之前就被提前注销。有状态预取或预渲染请求可能会产生不可预测的影响，有可能改变客户端尚未确认的操作的服务器状态。通过只允许对已经在我们 CDN 缓存中的页面进行预取，我们可以确保这些页面不会对用户体验产生负面影响。
这些防护旨在在性能敏感的环境中工作。我们在 2024 年 7 月初测量了我们的基线保守部署模型对 Cloudflare 开发人员文档所有页面的影响。我们发现我们能够预取正确的内容，这些是 94% 的时间用户会导航到的内容。我们同时提高了导航性能，将 p75 分位数的 LCP 降低了 40%，而没有产生任何意外的副作用。结果非常棒！
我们的全球网络覆盖超过 330 座城市，与 95% 的互联网用户连接延迟不超过 50 ms。这种广泛的覆盖使我们能够为客户显著提高可缓存资产的性能。通过 Speed Brain 利用这个网络进行智能预取， Cloudflare 可以直接从 CDN缓存提供预取的内容，将网络延迟降低到接近即时的程度。
凭借在网络上的独特位置，我们能够自动启用 Speed Brain，无需客户对其源站配置进行任何更改。就像拨动开关那么简单。Speed Brain 的第一个版本现已上线。
当收到从启用 Speed Brain 的网页发出的请求时，Cloudflare 服务器会返回一个额外的“Speculation-Rules” HTTP 响应头。此标头的值是一个 URL ，指向一个带有固定规则配置的页面（如上所述）。
当浏览器开始解析响应标头时，它会获取我们的 Speculation-Rules 配置，并将其作为网页的一部分加载。
该配置指导浏览器根据访问者与页面的互动情况，决定何时从 Cloudflare 预取访问者可能会导航到的下一个页面。
当用户操作（例如，在下一页链接上单击鼠标事件）触发规则应用时时，浏览器会使用“sec-purpose: prefetch”HTTP 请求标头发送对该页面的预取请求。
我们的服务器解析请求表头以识别预取请求。如果请求的内容在我们的缓存中，我们就返回它；否则，返回 503 HTTP 状态码并拒绝预取请求。这消除了向未意识到预取的源或 Cloudflare Workers 发送请求所带来的不安全副作用的风险。只有缓存中独有的内容会被返回。
在成功响应时，浏览器会将内容成功预取到内存中，当访问者导航到该页面时，浏览器会直接从缓存中加载网页，实现即时渲染。
对 Speed Brain 的支持依赖于 Speculation Rules API ，这是一个新兴的 Web 标准。截至 2024 年 9 月，对这一新兴标准的支持限于基于 Chromium 的浏览器（版本 121 或更高版本） ，例如 Google Chrome 和 Microsoft Edge。随着 Web 社区就 API 标准化达成共识，我们希望看到它在其他浏览器供应商中得到更广泛的采用。
预取本质上不适用于动态内容，因为此类内容的状态会发生变化，这可能导致将陈旧或过时的数据交付给最终用户，并增加源站负载。因此，Speed Brain 仅适用于您网站缓存在我们网络上的非动态页面。它不会影响动态页面的加载。为了从 Speed Brain 中获得最大的好处，我们建议使用缓存规则来确保您网站上的所有静态内容（尤其是 HTML 内容）都符合缓存的条件。
当浏览器响应一个预取请求（由 sec-purpose: prefetch 标头标记）而收到 503 HTTP 状态码时，它取消预取尝试。尽管浏览器控制台中显示 503 错误似乎令人担忧，但它对于取消预取请求是完全无害的。在我们的早期测试中，503 响应代码引起了一些网站所有者的顾虑。我们正在与合作伙伴合作对此问题进行迭代，以改善客户端体验，但目前请遵循规范指导 ，即建议显示 503 响应，以便浏览器安全地丢弃预测请求。根据早期 beta 测试人员的反馈，我们正在与 Chrome 进行积极讨论，并相信一个新的非错误专用响应代码会更合适，能减少混淆。同时，Speed Brain 相关预取请求的 503 响应日志是无害的。如果您所用的工具难以忽略这些请求，您可以暂时禁用 Speed Brain，直到我们与 Chrome 团队一起研究出更好的方法。
此外，当网站同时使用自己的自定义预测规则和 Cloudflare 的 Speed Brain 功能时，两个规则集可以同时运行。Cloudflare 的防护措施将预测规则限制在可缓存的页面上，这对那些已有实现的人来说可能是一个意外的限制。如果您观察到这种行为，请考虑为您的站点禁用其中一个实现，以确保行为的一致性。请注意，如果您的源服务器响应包含 Speculation-Rules 标头，则其不会被覆盖。 因此，潜在的规则集冲突主要涉及预定义的内联预测规则。
一般而言，我们建议您在使用 Speed Brain 和大多数其他 Cloudflare 性能功能时，同时启用我们的 RUM 性能测量工具。我们的 RUM 功能帮助开发人员和网站运营商了解他们的最终用户体验应用性能的情况，提供对如下方面的可见性：
加载：内容需要多长时间才会可用？
交互性：网站与您交互时的响应速度如何？
视觉稳定性：加载时页面的移动幅度。
启用 RUM 后，您可以导航到仪表板中的 Web Analytics 部分，查看有关 Speed Brain 如何帮助减少 Core Web Vitals 指标中的延迟的重要信息，例如最大内容绘制 (LCP) 和加载时间。
示例 RUM 仪表板 ：一个拥有大量可预取内容的网站，在 9 月 16 日左右启用了 Speed Brain。
我们已在所有 Free 计划中默认启用此功能，并观察到以下情况：
Cloudflare 目前有数千万个域使用了 Speed Brain。我们测量了这些站点在第 75 分位点（p75）的 LCP，发现改善幅度在 40% 到 50% 之间（平均约 45%）。
这种改善是通过比较同一组域的导航预取和正常（非预取）页面加载进行比较得出的。
启用 Speed Brain 之前， Cloudflare p75 的免费网站体验到的 LCP 时间约为 2.2 秒。启用 Speed Brain 后，这些站点的 LCP 延迟显著减少了。总的来说，Speed Brain 低端节省了大约 0.88 秒，每次成功的预取节省了多达 1.1 秒！
目前，Speculation Rules API 仅在 Chromium 浏览器中可用。从Cloudflare Radar 中，我们可以看到大约 70% 的访问者请求来自 Chromium （Chrome、Edge 等）浏览器。
Cloudflare 每天处理数千亿个 HTML 内容请求。在这些请求中，大约一半已被缓存（确保您的 HTML 是可缓存的）。其中大约有 1% 是访问者发出的导航预取请求。这意味着，启用 Speed Brain 的网站的访问者每天都可以节省大量资源。每 24 小时， Speed Brain 就能避免相当于超过 82 年的延迟！
今天提供的 Speed Brain 功能只是开始。进入 2025 年，我们有许多令人兴奋的新增功能等待探索和发布。
我们在互联网上的独特地位为我们提供了有关 Web 浏览模式的宝贵见解，我们可以利用这些见解来提高 Web 性能，同时保护个人用户的隐私。通过使用一种通用的数据驱动的机器学习方法，我们可以为用户的页面定义更准确、特定于站点的预取预测器。
我们正在开发一种自适应预测模型，将显著改善我们目前保守提供的产品。此模型使用一种保护隐私的方法，根据每个站点的 Referrer 标头为该站点生成用户浏览图。对于通过导航跳转连接的任何两个页面，我们的模型会使用从我们聚合的流量数据中提取的见解来预测典型用户在这两个页面之间移动的可能性。
这个模型使我们能够根据您网站上每个相关的下一页链接的自定义紧迫性值定制规则集。对于模型预测用户导航信心较高的页面，系统会积极进行预取或预渲染。如果模型没有为某个页面提供规则，它将默认采用我们现有的保守方法，维持基线 Speed Brain 模型的优势。这些信号引导浏览器预取和预渲染适当的页面，这有助于加快用户导航，同时维持我们现有的安全防护措施。
在实验室测试中，我们的机器学习模型将 LCP 延迟改善了 75%，并以约 98% 的准确率预测访问者导航，确保正确的页面被预取，从而避免用户资源浪费。随着我们努力扩展此解决方案的规模，我们专注于定期训练模型，以适应不断变化的用户行为和不断发展的网站。使用在线机器学习方法将大大减少对任何手动更新和内容漂移的需求，同时保持高准确性——Speed Brain 负载解决方案会随着时间变得越来越智能！
如前所述，我们相信，我们的 RUM 工具就 Speed Brain 如何帮助提高您的网站性能提供了最佳见解。未来，我们计划提供按导航类型过滤 RUM 工具的功能，以便您可以比较预取内容与非预取内容的浏览器渲染。
我们目前提供预取可缓存内容的能力。预取会在用户导航之前下载页面的主文档资源，但不会指示浏览器预渲染页面或下载任何其他子资源。
未来，Cloudflare 的 Speed Brain 服务将把内容预取到我们的 CDN 缓存中，然后与浏览器合作，了解哪些是最适合预渲染的内容。这将帮助使静态内容更接近于即时渲染。
Argo Smart Browsing：Speed Brain 与 Smart Routing
在初始实现中，Speed Brain 提供了令人难以置信的性能提升，同时维持保守：从迫切程度和资源消耗的角度来看均如此。
正如本文前面所述，在实验室中测试了一个更积极的模型，由机器学习和更高的紧迫性值驱动，将LCP 降低了 75%。我们正在研究将 Speed Brain 的这一更积极的额外实现与 Argo Smart Routing 捆绑到一个名为“Argo Smart Browsing”的产品中。
Cloudflare 客户可以继续免费使用 Speed Brain，但那些想要获得进一步性能提升的客户将能够一键启用 Argo Smart Browsing。借助 Argo Smart Browsing，由于采用了更激进的模型，不仅可缓存的静态内容在浏览器中的加载速度提高了 75%，在无法缓存内容且请求必须转发到源站服务器的情况下，相关内容通过性能最佳的网络路径发送 ，带来平均 33% 的性能提升。性能优化应用于请求生命周期的几乎每一个阶段，无论内容是静态或动态，缓存或未缓存。
要开始使用 Speed Brain，请在Cloudflare仪表板中导航至“速度” >“优化”>“内容优化”> “Speed Brain” 来启用。就是什么简单！该功能也可以通过 API 启用。Free 计划域名默认已启用 Speed Brain。
我们强烈建议客户也启用 RUM （位于仪表板的同一部分），以了解 Speed Brain 以及其他 Cloudflare 功能和产品所提供的性能提升。
我们很高兴能继续构建使 Web 性能变得可靠、快速的产品和功能。如果您是工程师，并有意为所有人提高 Web 性能，欢迎加入我们！