现代用户期望即时、可靠的网络体验。当您的应用程序运行缓慢时，用户不仅会抱怨，还会离开。即使是100毫秒的微小延迟，也会对收入、转化率、跳出率、参与度等产生可衡量的影响。
如果您负责满足用户对这些体验的期望，您会知道有许多监控工具可以显示访问者如何体验您的网站，并在网站运行缓慢或出现问题时发出提醒。这很重要，但我们相信了解状况只是成功的一半。真正的价值在于将监控和修复整合在同一视图中，让客户能够快速识别和解决问题。
这就是为什么今天我们激动地推出全新升级的Observatory，现已进入公开测试阶段。这款监控和可观测工具不仅提供图表，还会确切地告诉您如何提高应用程序的性能和弹性，并立即显示这些更改的影响。我们将其提供给所有订阅层级（包括免费版！），即日可用。
但是，等等，还有更多！为了让您的用户在Cloudflare上的体验更快，我们推出了Smart Shield，即日面向所有订阅层级开放。使用Observatory，您可以精确定位性能瓶颈，而对于许多最常见的问题，您现在可以通过我们的Smart Shield产品，只需点击几下即可应用修复。双重乐趣！
我们的独特视角：利用全球20%网络的数据
每天，Cloudflare处理全球超过20%的网络流量，这使我们能够独特地洞察什么能让网站更快、更有弹性。我们构建Observatory就是为了利用这一优势，将通常分散在不同工具中的数据——包括真实用户数据、合成测试、错误率和后端遥测——统一到一个平台中。这使您能够在一个地方全面、连贯地了解应用程序的端到端健康状况，并轻松识别和解决性能问题。
在此次发布中，我们整合了以下内容：
- 真实用户数据：查看您的应用程序在真实世界中对真实用户的性能表现。
- 后端遥测：分解请求的生命周期，以精确定位需要改进的领域。
- 错误率：了解您的应用程序在边缘和源站的稳定性。
- 缓存命中率：确保您最大限度地发挥配置的性能。
- 合成测试：通过强大、准确的模拟，主动测试和监控关键端点。
让我们快速浏览每个数据集，看看我们如何在Observatory中使用它们。
真实用户数据
数据收集有两种主要形式：真实用户数据和合成数据。真实用户数据是从真实流量、真实访问者到您的应用程序收集的性能指标。它反映了用户在现实世界中实际看到的应用程序性能。它是不可预测的，并覆盖了所有场景。
合成数据是使用某种模拟测试（在无头浏览器中加载站点、从测试系统向端点发出网络请求等）收集的数据。测试在一组预定义的特征（位置、网络速度等）下运行，以提供一致的基线。
这两种形式的数据都有其用途，具有强大运营卓越文化的公司倾向于同时使用两者。
当您访问Observatory时，首先看到的数据是使用真实用户监控（RUM）收集的真实用户数据，特别关注核心网页指标。
这是非常有意的。
在衡量应用程序的性能和弹性时，真实用户数据应该是真相的来源。即使是最好的合成数据源也始终是一种近似。它们无法覆盖所有可能的场景，并且由于它们是从实验室环境运行的，它们并不总能揭示可能更零星和不可预测的问题。
它们也是用户访问您的网站时所体验的最佳代表，归根结底，这就是为什么我们专注于为用户提高性能、弹性和安全性。
我们坚信每个公司都能访问准确、详细的RUM数据的重要性，因此我们向所有账户免费提供。事实上，我们即将默认为我们所有的免费区域提供我们的隐私优先分析——该分析不跟踪单个用户进行分析（不包括来自欧盟或英国访问者的数据），无需设置。我们认为正确的事情是为每个人提供详细、可操作的、真实的用户数据，并且我们希望使其变得容易。
后端遥测
前端性能指标是我们理解应用程序实际用户体验的最佳代理，因此，它们作为关键绩效指标（KPI）非常有效。
但这还不够。每个主要指标都应有一定程度的支持性诊断指标，帮助我们理解为什么我们的用户指标会这样表现——以便我们能够快速识别问题、瓶颈和改进领域。
虽然行业在很大程度上已经正确地不再将首字节时间（TTFB）作为主要关注指标，但它作为诊断指标仍然有价值。事实上，我们分析了我们的RUM数据，发现首字节时间和最大内容绘制（LCP）之间有非常强的联系。
Google推荐的首字节时间阈值是：
- 良好：<= 800毫秒
- 需要改进：> 800毫秒且 <= 1800毫秒
- 差：> 1800毫秒
同样，他们对最大内容绘制的官方阈值是：
- 良好：<= 2500毫秒
- 需要改进：> 2500毫秒且 <= 4000毫秒
- 差：> 4000毫秒
通过查看超过90亿个事件，我们发现与平均站点相比，具有“差”（>1800毫秒）TTFB的站点：
- 拥有“良好”LCP的可能性低70.1个百分点
- 拥有“需要改进”LCP的可能性高21.9个百分点
- 拥有“差”LCP的可能性高48.2个百分点
TTFB是一个定义不清的黑盒，因此我们特意将其分解为各个子部分，以便您快速确定问题是与连接建立、服务器响应时间、网络本身等有关。在接下来的几个月里，我们将进一步分解这一点，因为我们暴露了请求的完整生命周期，以便您能够精确定位瓶颈所在。
错误与缓存比率
稳定性和性能的下降通常与配置更改或错误增加直接相关。对这些特征的清晰可见性通常可以直接切入当前问题的核心，并指出提高应用程序整体效率和有效性的机会。
Observatory突出显示了边缘和源站的缓存命中率和错误率。这与后端遥测很好地互补，并有助于进一步分解您看到的后端指标，以帮助精确定位需要改进的领域。
以缓存命中率为例。直观上，我们知道当内容从边缘服务器的缓存中提供时，它应该比请求必须一直返回到源服务器时更快。根据我们的数据，再次证实，这正是我们所看到的。
如果我们再次考虑我们的首字节时间阈值（良好是<= 800毫秒；需要改进是> 800毫秒且小于1800毫秒；差是任何超过1800毫秒），在查看我们的RUM解决方案收集的90亿个数据点时，我们看到从Cloudflare缓存提供的所有页面中，高达91.7%的页面具有“良好”的TTFB，而当请求必须从源服务器提供时，这一比例为79.7%。
换句话说，优化源站性能（稍后会详细说明）并将更多内容移至边缘是确保您获得更强性能基线的可靠方法。
准确详细的合成测试
虽然真实用户数据是我们的真相来源，但合成测试和监控也很重要。因为测试是在更受控的环境中运行的（从这个位置、在这个时间、使用这个标准等进行测试），结果数据的噪声和可变性要小得多。此外，由于没有用户参与，我们不必担心任何观察者效应，合成测试能够获取更多关于请求和页面生命周期的信息。
因此，合成数据非常适合于为工程师提供调试信息，以及为比较和对比不同平台、发布和其他情况下的结果提供更清晰的数据集。
Observatory提供两种不同类型的合成测试。
第一种合成测试是浏览器测试。浏览器测试将在无头浏览器中加载请求的页面，运行Google的Lighthouse来报告关键性能指标，并提供一些简单的改进建议。
第二种Observatory提供的合成测试是网络测试。这是Cloudflare中一个全新的测试类型，专注于让您更好地了解端点的网络和后端性能。
每个网络测试将访问提供的测试端点，并记录等待时间、服务器响应时间、连接时间、SSL协商时间和端点响应的总加载时间。因为这些测试更有针对性，单个测试本身的价值不大，并且容易产生变化。这种变化不一定是坏事——事实上，这些结果的可变性实际上可以让您更好地了解真实用户访问同一端点时的结果范围。
因此，网络测试会在短时间内对提供的端点触发一系列单独的运行。每个响应的数据都被记录，然后在测试结果页面上以直方图的形式呈现，让您不仅看到单个数据点，还能看到每个指标的长尾和短尾分布。这比单次测试运行能提供更准确的实际表现。
您还可以通过选择两个已完成的网络测试，在Observatory中比较网络测试。同样，每个测试的所有数据点将以直方图形式提供，您可以轻松比较两者的结果。
我们正在努力在2025年第四季度改进这两种合成测试类型，重点是使它们更强大和更具诊断性。
正如我们之前提到的，即使在最好的情况下，合成数据也是对实际发生情况的近似。准确性至关重要。不准确的数据可能会因可变性和错误测量而分散团队的注意力。
重要的是这些工具尽可能准确和真实。对我们来说，回馈社区也很重要，既因为这是正确的事情，也因为我们相信，对我们使用的测量工具和框架拥有最高信心的最佳方式是开源提供的严谨和审查。
出于这些原因，我们将致力于开源许多我们用于支持Observatory的测试代理。我们将很快分享更多相关信息，以及我们如何构建每个不同测试工具及其原因的更多细节。
采取行动：智能建议
人们测量不是为了拥有数据和漂亮的图表。他们测量是因为他们希望能够掌握应用程序的健康状况并找到改进的方法。数据是容易的。理解如何处理呈现给您的数据是最困难也是最重要的部分。
没有行动的监控是无用的。
我们构建Observatory是为了坚定不移地关注可操作性。在呈现任何新指标之前，我们会花一些时间探讨该指标为何重要，何时值得解决，以及如果这些指标需要改进，您应该采取什么行动。
所有这些将我们引向新的智能建议。只要可能，我们希望将每个指标与一组有主见的、数据驱动的建议配对，以说明如何改善情况。我们希望避免模糊的、挥手式的建议，而是提供规范性的、具体和精确的建议。
例如，让我们看看我们提供的关于改进最大内容绘制的一项特定建议。
最大内容绘制是一个核心网页指标，测量屏幕上显示最大内容块的时间。该内容块可以是图像、视频或文本。
很像TTFB，最大内容绘制本身有点像一个黑盒。虽然它告诉我们该内容显示在屏幕上需要多长时间，但有许多潜在的瓶颈可能导致延迟。也许服务器响应时间非常慢。或者可能有什么东西阻止了内容在页面上显示。如果对象是图像或视频，也许文件大小很大， resulting 下载速度慢。LCP本身没有给我们那种粒度，因此很难提供比挥手式指导更多的内容来解决问题。
幸运的是，就像我们可以将TTFB分解为子部分一样，我们也可以将LCP分解为其子部分。具体来说，我们可以查看：
- 首字节时间：服务器响应HTML请求的速度
- 资源加载延迟：TTFB之后浏览器发现LCP资源需要多长时间
- 资源加载持续时间：浏览器下载LCP资源需要多长时间
- 渲染延迟：浏览器在获得资源后渲染内容需要多长时间
通过将其分解为这些子部分，我们可以更具诊断性地知道该做什么。
在上面的例子中，我们的推荐引擎分析站点的真实用户数据，并注意到资源加载延迟占总LCP时间的10%以上。因此，触发LCP的资源很可能很大，并且可能被压缩以减少文件大小。因此，我们建议使用Polish启用压缩。
我们对这些建议在帮助每个人快速锁定有意义的解决方案以改善性能和弹性方面的影响感到非常兴奋，而无需翻阅大量数据才能到达那里。随着我们分析数据，我们将发现越来越多的问题模式及其可以映射到的解决方案。扩展我们的智能建议将是我们前进过程中持续关注的重点，我们正在努力在第四季度添加更多关于这些模式和我们发现的内容。
解决最大的痛点：Smart Shield
Observatory让您对应用程序的健康状况有了前所未有的洞察力，但洞察力只是成功的一半。下一个挑战是根据它们采取行动，这给我们带来了另一层复杂性：保护您的源站。对于我们许多客户来说，正确管理源站路由和连接是整体聚合性能的最大驱动因素之一。正如我们之前提到的，当我们必须返回源站时，我们看到对面向用户的性能指标有明显的负面影响，我们希望让我们的客户尽可能容易地改善这些体验。实现这一点需要防止不必要的负载，同时确保只有受信任的流量到达您的服务器。
今天的客户拥有强大的工具来保护他们的源站，但实现基本用例仍然令人沮丧地复杂：
- 使应用程序更快
- 减少源站负载
- 理解源站健康问题
- 限制对源服务器的IP地址访问
这些基本需求目前需要导航多个API和仪表板设置。您不应该需要成为每个功能的专家——我们应该分析您的流量模式并提供清晰、可操作的解决方案。
Smart Shield：源站保护的未来
Smart Shield将源站保护从一个复杂的、多工具的挑战转变为一个代表您工作的流线型、智能解决方案。我们统一的API和UI将所有源站保护要点——动态流量加速、智能缓存、健康监控和专用出口IP——整合到一个地方，实现一键配置。
但我们没有止步于简化。Smart Shield与Observatory集成，既提供“什么”——识别性能瓶颈和健康问题——也提供“如何”——提供提高性能、可用性和安全性的能力。
这创建了一个连续的反馈循环：Observatory识别问题，Smart Shield提供解决方案，实时分析验证影响。
但这对您意味着什么？
- 降低总拥有成本（TCO）
- 缩短与客户源站相关的性能、可用性和安全问题的价值实现时间（TTV）
- 无需猜测即可启用新功能，并在数据中验证有效性
您的时间可以继续专注于构建出色的用户体验，而不是成为配置专家。我们很高兴能让您为您的客户和工程师节省时间，同时为您确保源站基础设施易于优化以取悦客户铺平道路。
通过智能连接重用保护和加速源站
保持您的源站快速和稳定是我们在Cloudflare所做工作的很大一部分。当您经历流量激增时，您最不希望的是大量的TLS握手击垮您的源站，或者这些新连接使您的请求停滞，让您的用户等待缓慢的页面加载。
这就是为什么我们对Cloudflare网络与您的源站通信的方式进行了重大更改，以显著提高我们的源站连接性能。
当Cloudflare向您的源站发出请求时，我们从每个Cloudflare数据中心可用机器的子集中发出请求，以便我们可以改善您的连接重用。直到现在，这个池的大小默认情况下在数据中心内的每个应用程序都是相同的，并且对特定客户的池大小的更改需要手动进行。这通常导致我们的客户连接重用不理想，因为我们可能从比实际需要多得多的机器发出请求，导致我们本可以拥有的预热连接池更少。这也时不时地给我们的数据中心带来问题，因为较大的应用程序可能拥有比默认池大小能够服务的更多流量，导致生产事件，工程师被呼叫并不得不手动增加特定客户的扇出因子。
现在，这些池大小是自动和动态确定的。通过跟踪数据中心内的域级流量量，我们可以自动扩大和缩小为任何特定客户的服务于客户源服务器的机器数量，从而提高客户网站的性能和我们网络的可靠性。一个庞大的、高流量的网站，拥有相当数量的API流量，将不再由与较小和更典型网站相同数量的机器处理。我们的系统可以在几秒钟内响应客户流量模式的变化，使我们能够快速增加并响应源站流量的激增。
由于这些改进，Cloudflare现在全面使用减少30%以上的连接与源站通信。为了更易于理解，这相当于每天在我们的全球流量中节省大约402年的握手时间，或每月节省12,060年的握手时间！这意味着仅仅通过Cloudflare代理您的流量，您将看到到您源站的连接数量平均减少30%，在服务相同流量的同时保持其更高的可用性，进而降低您的出口费用。但是，在许多情况下，观察到的结果可能远大于30%。例如，在一个API流量特别大的数据中心，我们看到源站连接减少了约60%！
许多人没有意识到，与源站建立更多连接需要更多计算和时间让系统创建TCP和SSL握手。这从为最终用户提供请求内容的时间中抽走，并可能对您的性能和整体应用程序构成隐性税收。我们自豪地通过寻找智能、创新的方式来减少所需连接数量同时支持相同流量，来减少互联网的隐性税收。
请关注2026年初Smart Shield的更多更新——我们正在努力为专用CDN出口IP地址添加自助服务支持，以及显著的性能、可靠性和弹性改进！
规划路线：Observatory和Smart Shield的下一步
我们今天非常兴奋地与大家分享这两款产品。Smart Shield和Observatory结合，提供了洞察力和轻松修复的强大组合拳。
在我们导航Observatory的测试版发布时，我们知道这仅仅是个开始。
我们对Observatory的愿景是成为您应用程序健康状况的单一真相来源。我们知道做出正确的决策需要健壮、准确的数据，我们希望为我们的客户提供最全面的图景。
在接下来的几个月里，我们计划继续推进我们的目标，即提供全面的数据，并辅以清晰的操作路径。
- 更深层次、更具诊断性的数据。我们将继续打破数据孤岛，引入更多指标，确保您对应用程序的健康状况有真正全面的了解。我们将专注于更深入和更具诊断性，分解请求和页面生命周期的每个方面，为您提供更细粒度的数据。
- 更多的解决方案路径。人们测量不是为了看数据，他们测量是为了解决问题。我们将继续扩展我们的建议，为您提供更精确、数据驱动的解决方案，以应对更广泛的问题，让您通过Smart Shield一键修复问题，并带来更紧密的反馈循环以验证配置更新的影响。
- 与其他产品进行基准测试。我们的一些客户由于监管或合规要求，在不同的CDN之间分割流量。自然，这带来了一系列关于比较分割流量性能的问题。在Observatory中，您今天就可以比较这些，但我们计划了很多事情来使这更容易。
今天就亲自试用Observatory和Smart Shield。如果您有让Observatory和Smart Shield更好的想法或建议，我们洗耳恭听，很乐意交流！
Cloudflare的连接云保护整个企业网络，帮助客户高效构建互联网规模的应用程序，加速任何网站或互联网应用程序，抵御DDoS攻击，阻止黑客，并可以帮助您完成零信任之旅。
从任何设备访问1.1.1.1，开始使用我们的免费应用程序，使您的互联网更快、更安全。
要了解我们帮助构建更好互联网的使命，请从这里开始。如果您正在寻找新的职业方向，请查看我们的空缺职位。