现代用户期望获得即时、可靠的网络体验。当您的应用运行缓慢时，他们不仅会抱怨，还会离开。即使只有 100 毫秒的延迟，也已证明会对收入、转化率、跳出率、参与度等产生可衡量的影响。
如果您负责满足产品用户的这些期望，您就会知道有很多监控工具可以展示访客的网站体验，并让您了解网站何时缓慢或出现问题。这至关重要，但我们认为了解具体情况只是成功的一半。真正的价值在于将监控和补救措施集成在同一视图中，使客户能够快速识别和解决问题。
因此，我们今天非常高兴地推出全新升级的 Observatory，现已进入开放测试阶段。这款监控和可观测性工具不仅提供图表和图形，还能精准地指导您如何提升应用的性能和韧性，并立即展示这些改进带来的影响。我们今天将向所有订阅层级（包括 Free 计划！）推出该功能。
不过别急，还有更多惊喜！为了让您的用户在 Cloudflare 中获得更快速的体验，我们今天为所有订阅层级推出了 Smart Shield 功能。使用 Observatory，您可以精准定位性能瓶颈，对于许多最常见的问题，现在只需点击几下，即可使用我们的 Smart Shield 产品快速修复。双重精彩，不容错过！
Cloudflare 每天处理超过 20% 的网络流量，这让我们拥有独特的优势，能够了解如何让网站更快、更具韧性。我们构建了 Observatory 来充分利用这一优势，将通常分散在不同工具中的数据（包括真实用户数据、综合测试、错误率和后端遥测数据）整合到一个平台中。这让您能够一站式全面、连贯地了解应用程序的端到端健康状况，并轻松识别和解决性能问题。
在此次发布中，我们将汇集：
真实用户数据：了解您的应用在真实世界中为真实用户提供的性能。
后端遥测：分解请求的生命周期，以确定需要改进的方面。
错误率：了解您的应用在边缘和源站的稳定性。
缓存命中率：确保您能最大限度地提升配置性能。
合成测试：利用强大而精确的模拟技术，主动测试并监控关键端点。
让我们快速浏览一下每个数据集，看看我们如何在 Observatory 中使用它们。
数据收集主要有两种形式：真实用户数据和合成数据。真实用户数据是从实际流量（来自实际访问者）收集的应用性能指标。它反映了用户实际看到的应用在现实世界中的运行情况。它不可预测，并且涵盖所有场景。
合成数据是使用某种模拟测试（在无头浏览器中加载网站、从测试系统向端点发出网络请求等）收集的数据。这些测试在一组预定义的特征（位置、网络速度等）下运行，以提供一致的基线。
这两种形式的数据各有其用途，而那些已经建立了强大运营卓越文化的公司往往会同时使用两者。
您访问 Observatory 时首先看到的数据是使用真实用户监控 (RUM) 收集的真实用户数据，尤其关注 Core Web Vital 指标。
这是有意为之的。
在衡量应用程序的性能和韧性时，真实用户数据应该是真相的来源。即使是最好的合成数据源也始终只是近似值。它们无法涵盖所有可能的情况，而且由于它们是在实验室环境中运行的，它们并不总是能揭示出那些可能更加偶发和难以预测的问题。
它们也是用户的网站访问体验的最佳体现，归根结底，这就是我们专注于为用户提高性能、韧性和安全性的原因。
我们深信，让每家公司都能获取准确、详尽的 RUM 数据至关重要，因此我们为所有帐户免费提供这一服务。事实上，我们即将把我们的隐私优先型分析服务（该服务在分析时不会追踪个人用户）默认开放给所有免费区域（不包括来自欧盟或英国访客的数据），无需任何配置。我们认为，正确的做法是为每个人提供详细、可操作的真实用户数据，并且我们希望让它触手可及。
前端性能指标是我们了解应用程序实际用户体验的最佳参考依据，因此，它们也非常适合作为关键绩效指标 (KPI)。
但这还不够。每个主要指标都应该有一定程度的支持性诊断指标，帮助我们理解为什么用户指标会呈现当前的表现——这样我们就能快速识别问题、瓶颈和需要改进的领域。
尽管业界已普遍（且合理地）不再将“首字节时间”(TTFB) 作为主要关注指标，但它仍然具有作为诊断指标的价值。事实上，我们分析了自身的 RUM 数据，发现首字节时间与最大内容绘制之间存在着非常强的关联。
Google 推荐的首字节时间阈值为：
良好：<= 800ms
需要改进：> 800ms 且 <= 1800ms
较差：> 1800ms
同样，他们对最大内容绘制的官方阈值是：
通过查看超过 90 亿个事件，我们发现与平均网站相比，TTFB 较差 (>1800ms) 的网站：
TTFB 是一个定义模糊的“黑盒”指标，所以我们特意将它拆解为多个子部分，让您能快速判断问题出在连接建立、服务器响应时间、网络本身，还是其他环节。未来几个月，我们会进一步细化这一拆分，完整呈现请求的整个生命周期，让您能够精准定位瓶颈究竟出现在哪个环节。
稳定性和性能的下降通常与配置更改或错误增加直接相关。清晰地了解这些特性通常可以直击问题的核心，并指出改进应用程序整体效率和有效性的机会。
Observatory 会突出显示边缘和源的缓存命中率和错误率。这很好地补充了后端遥测数据，并有助于进一步细分您所看到的后端指标，从而帮助您找出需要改进的地方。
以缓存命中率为例。凭直觉我们就知道，当内容从边缘服务器的缓存中提供时，应该比请求必须回源到源服务器更快。根据我们的数据，结果也确实如此。
如果我们再次考虑我们的“首字节时间”阈值（“良好”是 <= 800ms；“需要改进”是 > 800ms 且小于 1800ms；“较差”是超过 1800ms），当查看由我们的 RUM 解决方案收集的 90 亿个数据点时，我们发现 Cloudflare 缓存提供的所有页面中有 91.7% 具有“良好”的 TTFB，而当请求必须从源服务器提供时，这一比例为 79.7%。
换句话说，优化源站性能（稍后会详细介绍）并将更多内容移至边缘是确保为您提供更强大性能基准的可靠方法。
虽然真实用户数据是我们的可靠来源，但合成测试和监控也同样重要。由于测试在更受控制的环境中运行（例如，在特定位置、特定时间、特定标准进行测试等），所得到的数据噪声更少、波动也更小。此外，由于没有用户参与，我们无需担心任何观察者效应，合成测试能够获取更多关于请求和页面生命周期的信息。
因此，合成数据非常适合为工程师提供调试信息，并提供更清晰的数据集，以便在不同平台、版本和其他情况下比较和对比结果。
Observatory 提供两种不同的合成测试类型。
第一个合成测试是浏览器测试。浏览器测试将在无头浏览器中加载请求的页面，并在其上运行 Google Lighthouse 来报告关键性能指标，并提供一些简单的改进建议。
Observatory 提供的第二种合成测试是网络测试。这是 Cloudflare 中一种全新的测试类型，旨在让您更好地了解端点的网络和后端性能。
每次网络测试都会访问指定的测试端点，并记录端点响应的等待时间、服务器响应时间、连接时间、SSL 协商时间以及总加载时间。由于这些测试更具针对性，单个测试本身的价值并不高，而且容易出现偏差。这种偏差并不一定是坏事——事实上，这些结果的差异实际上可以让您更好地了解真实用户访问同一端点时结果的广度。
因此，网络测试会在短时间内针对指定的端点触发一系列单独的运行。每次响应的数据都会被记录下来，然后在测试结果页面上以直方图的形式呈现，让您不仅可以看到单个数据点，还能看到每个指标的长尾和短尾分布。这比单次测试运行能提供更准确的现实表现。
您还可以在 Observatory 中比较两个已完成的网络测试。同样，每个测试的所有数据点都将以直方图的形式呈现，方便您轻松比较两个测试的结果。
我们计划在 2025 年第四季度改进这两种合成测试类型，重点是提高其性能和诊断能力。
正如我们之前提到的，即使在最佳情况下，合成数据也只是对实际情况的近似。准确性至关重要。不准确的数据可能会因数据波动和测量错误而分散团队的注意力。
这些工具必须尽可能准确，并贴近现实世界，这一点至关重要。回馈社区对我们来说也同样重要，因为这是正确的做法，也因为我们相信，对所使用的测量工具和框架保持最高信任度的最佳方式，就是依靠开源提供的严谨和审查。
基于以上原因，我们将致力于开源用于驱动 Observatory 的许多测试代理。我们很快会分享更多相关信息，包括每个测试工具的构建方式及其背后的设计考量。
人们进行数据测量并非为了获得数据和漂亮的图表，而是为了更好地掌握应用程序的运行状况并找到改进方法。数据本身并不难获取，难的是如何理解并利用这些数据，这才是最难也是最重要的部分。
只监控而不采取行动毫无意义。
我们构建 Observatory 的宗旨是始终关注可操作性。在提出任何新指标之前，我们都会花时间探讨该指标的重要性、何时值得关注，以及如果这些指标需要改进，您应该采取哪些行动。
所有这一切都促成了我们全新的“智能建议”功能的诞生。我们希望尽可能地将每项指标与一系列基于数据并带有主观见解的建议相结合，以期改进现状。我们力求避免含糊不清的建议，而是提供具体、精准的指导。
例如，让我们来看一个我们针对改进最大内容绘制提出的具体建议。
最大内容绘制 (LCP) 是一个核心 Web 指标，用于测量最大的内容何时显示在屏幕上。该内容可以是图像、视频或文本。
与 TTFB 类似，最大内容绘制 (LCP) 本身也是一个黑匣子。虽然它能告诉我们内容加载到屏幕上所需的时间，但造成延迟的潜在瓶颈有很多。例如，服务器响应速度可能非常慢；或者某些因素阻碍了内容在页面上的显示；如果对象是图像或视频，则可能是文件过大导致下载速度缓慢。LCP 本身无法提供如此精细的细节，因此很难给出具体的解决方案，只能给出一些笼统的指导。
值得庆幸的是，就像我们可以将 TTFB 分解成子部分一样，我们也可以将 LCP 分解成子部分。具体来说，我们可以考察以下几个方面：
首字节时间：服务器响应 HTML 请求的速度有多快
资源加载延迟：在 TTFB 后，浏览器需要多长时间才能发现 LCP 资源
资源加载持续时间：浏览器下载 LCP 资源需要多久
渲染延迟：指浏览器在获得资源后，渲染内容所需的时间。
将其分解为这些子部分后，我们就能更准确地诊断出该怎么做。
在上面的例子中，我们的推荐引擎分析了网站的真实用户数据，发现资源加载延迟占总 LCP 时间的 10% 以上。因此，触发 LCP 的资源很可能很大，可以通过压缩来减小文件大小。所以我们建议使用 Polish 进行压缩。
我们非常高兴这些建议能够帮助大家快速找到切实可行的解决方案，从而提升性能和韧性，而无需耗费大量时间去分析海量数据。随着数据分析的深入，我们将发现越来越多的问题模式以及与之对应的解决方案。我们将持续改进智能建议，并致力于在第四季度发布更多关于这些模式及其发现的内容。
Observatory 让您以前所未有的方式深入了解应用程序的运行状况，但这仅仅是成功的一半。接下来的挑战是如何根据这些洞察采取行动，这就引出了另一个复杂的层面：保护您的源站。对于我们的许多客户而言，妥善管理源站路由和连接是提升整体性能的关键因素之一。正如我们之前提到的，当需要回溯源站时，用户体验指标会受到明显的负面影响，因此我们希望尽可能简化客户改善用户体验的过程。要实现这一点，需要防止不必要的负载，同时确保只有可信流量才能到达您的服务器。
如今的客户拥有强大的工具来保护其源服务器，但实现基本用例仍然非常复杂：
加快应用程序运行速度
降低源站负载
了解源站运行状况问题
限制对源服务器的 IP 地址访问权限
目前，满足这些基本需求需要您操作多个 API 和仪表板设置。您无需成为每个功能的专家——我们应该分析您的流量模式，并提供清晰、可行的解决方案。
Smart Shield 将源站保护从一项复杂的多工具挑战转变为一个精简、智能的解决方案，为您高效工作。我们统一的 API 和用户界面将包括动态流量加速、智能缓存、健康监控和专用出口 IP 在内的所有源站保护要素整合到一个平台，只需单击即可完成配置。
Smart Shield 与 Observatory 平台集成，不仅能告诉您“是什么”——即识别性能瓶颈与健康问题，还能为您提供“怎么做”——通过一系列功能来提升性能、可用性与安全性。
这形成了一个持续的反馈循环：Observatory 识别问题，Smart Shield 提供解决方案，实时分析验证影响。
但这对您意味着什么？
您可以将时间专注于打造卓越的用户体验，而不是成为配置专家。我们很高兴能为您节省时间，让您更好地服务客户和工程师，同时帮助您轻松优化源站基础设施，从而提升客户满意度。
保持源服务器快速稳定是 Cloudflare 的一项重要工作。当流量激增时，您最不希望看到的就是大量的 TLS 握手 导致源服务器宕机，或者这些新连接阻塞请求，让用户苦等页面加载缓慢。
因此，我们对 Cloudflare 的网络与您的源站通信的方式进行了重大更改，以显著提高源站连接的性能。
当 Cloudflare 向您的源服务器发出请求时，我们会从每个 Cloudflare 数据中心内一部分可用机器中发起连接，以便提高您的连接重用率。此前，数据中心内所有应用程序的此连接池默认大小相同，需要手动更改特定客户的连接池大小。这通常会导致客户的连接重用率不理想，因为我们可能使用了远超实际需求的机器发出请求，从而导致可用连接池的数量少于预期。这也不时会给我们的数据中心造成问题，因为较大的应用程序拥有的流量可能超过默认池大小的服务能力，从而导致生产环境中的事故，工程师接到通知后不得不手动增加特定客户的扇出因子。
现在，这些资源池的大小是自动动态确定的。通过跟踪数据中心内的域名级流量，我们可以自动扩展或缩减服务于特定客户源服务器流量的机器数量，从而提升客户网站的性能和网络可靠性。一个拥有大量 API 流量的大型高流量网站，将不再与一个更小型、更常规的网站使用相同数量的机器来处理请求。我们的系统能够在几秒钟内响应客户流量模式的变化，从而快速提升资源容量并应对源服务器流量的激增。
得益于这些改进，Cloudflare 现在与源站通信的连接数整体减少了 30% 以上。为了更直观地理解，这意味着我们每天在全球流量中节省了约 402 年的握手时间，每月节省了 12,060 年的握手时间！也就是说，只需通过 Cloudflare 代理您的流量，您就能看到源站连接数平均减少 30%，从而在处理相同流量的同时保持更高的可用性，进而降低您的输出费用。但在许多情况下，实际效果远不止 30%。例如，在一个 API 流量特别大的数据中心，我们发现源站连接数减少了约 60%！
很多人并没有意识到，与源站建立更多连接，意味着系统需要消耗更多的计算资源和时间来完成 TCP 和 SSL 握手。这会挤占本应用于服务终端用户请求内容的时间，从而对您的性能乃至整个应用造成一种隐性开销。我们很自豪能够减少互联网中的这种隐性成本，通过智能、创新的方式，在保障同等流量规模的前提下，减少所需的连接数量。
敬请期待 Smart Shield 在 2026 年初的更多更新——我们正在努力为专用 CDN 输出 IP 地址添加自助服务支持，以及显著的性能、可靠性和韧性改进！
规划路线：Observatory 和 Smart Shield 的后续步骤
我们非常高兴今天能与大家分享这两款产品。Smart Shield 和 Observatory 强强联合，可提供强大的洞察力和便捷的修复方案。
在我们推进 Observatory 测试版发布之际，我们知道这仅仅是个开始。
我们的愿景是让 Observatory 成为您应用程序健康状况的唯一权威来源。我们深知，做出正确的决策需要强大而准确的数据，因此我们希望为客户提供最全面的信息。
在接下来的几个月里，我们计划继续推进我们的目标，即提供全面的数据，并辅以清晰的行动方案。
更深入、更全面的诊断数据。我们将继续打破数据孤岛，引入更多指标，确保您能够真正全面地了解应用程序的运行状况。我们将专注于更深入、更具诊断性地分析请求和页面生命周期的各个方面，为您提供更精细的数据。
更多解决方案路径。人们进行测量并非为了查看数据，而是为了解决问题。我们将继续扩展我们的建议，为您提供更精准、更贴合数据驱动的解决方案，以应对更广泛的问题，让您只需单击一下即可通过 Smart Shield 修复问题，并建立更紧密的反馈循环，以验证配置更新的影响。
与其他产品进行基准对比。由于监管或合规性要求，我们的一些客户会将流量分配到不同的 CDN 上。这自然会引发一系列关于比较不同流量分支性能的问题。目前，您可以在 Observatory 中比较这些流量，但我们计划推出更多功能，让比较更加便捷。
立即体验 Observatory 和 Smart Shield。如果您有任何关于改进 Observatory 和 Smart Shield 的想法或建议，我们非常愿意倾听，期待与您交流！