2025 年的真实性能改进

客户和最终用户现在比以往任何时候都更需要即时交互。性能仍然是您取得成功的关键，Google 等公司已将性能确立为搜索结果中的一项关键排名因素。Akamai 在网站性能方面进行了大量投资。通过使用我们的改进和新功能，您可以为真实客户实现最佳的应用程序性能。

在本博文中，我们将展示相关改进对客户的核心网页指标 (CWV) 所产生的积极影响。作为 SEO 排名信号，CWV 已成为审视真实性能的事实标准，在 2025 年尤其如此。我们使用 CWV 是因为它专注于真实用户在使用现代应用程序时的体验，而不考虑他们使用的连接、位置、浏览器或设备。

接下来，我们将向您展示如何使用这些优化来提高您的应用程序性能；这其中包括我们推出的优化以及一些功能和控件，您现在可以将它们添加到自己的 Akamai 配置中，从而加快网站和应用程序的运行速度。

让我们开始吧。

我们去年推出的性能改进为真实用户带来了了切实、可衡量的影响。Google 通过 Chrome 用户体验报告 (CrUX) 证实了这一点。CrUX 是由 Google 提供的一个公开数据集，可帮助相关人员深入了解真实用户在网站性能和加载时间方面的体验。

这些数据是从已选择加入相关计划的实际用户处收集的，这使得 Google 能够跟踪和汇总反映基本用户交互而不是反映模拟测试或基于实验室测试的指标。

借助 Akamai 的新功能，我们在以用户为中心的关键性能指标 (KPI) 方面看到了更好的结果，例如最大内容渲染时间、从交互到下一次渲染时间，以及首字节到达时间（技术性更强但仍然很受欢迎）。我们来看看这些网页指标出现积极变化的一些网站示例。

注意：以下各图是来自优秀的 treo.sh 工具的屏幕截图，您可以利用该工具对此数据集中所有网站的历史 CrUX 数据实现可视化。

该图表顶部的绿色部分显示了其 LCP 低于 2.5 秒的请求所占百分比。它还显示，与前三个月相比，二月以来拥有“良好”（绿色）用户体验（LCP 低于 2.5 秒）的用户增加了 20%。

该网站经常处于“需要改进”区域（橙色），并且可能在 Google 搜索结果中受到惩罚，但现在他们已稳居绿色区域，这是用户满意度得到提升的强烈信号。

一家注重安全的银行在从交互到下一次渲染的时间 (INP) 方面实现了显著改进（图 2）。他们不仅进行了自己的实施改进，还从我们过去几个月内发布的多项 Akamai Bot Manager JavaScript 优化中受益匪浅。该银行的 INP 得到了持续改善，拥有“良好”体验（INP < 200 毫秒）的用户占比从大约 55% 增加到超过 87%。

虽然此指标本身并非 CWV 指标，但首字节到达时间 (TTFB) 仍然是一项重要的跟踪指标，因为它通常与 LCP 密切相关。

随着平台的改进，一个运行速度已经很快的电子商务网站在过去八个月里的运行速度更上一层楼（更多内容参见“我们进行了哪些方面的改进？”部分）。图 3 显示，随着 Akamai 平台的发布，该网站上拥有良好 TTFB 体验的用户占比持续增加。

旅游行业的另一位客户一直以来饱受 TTFB 数据不达标的困扰，他们并未使用 Akamai 提供的性能优化措施。在实施了 Akamai 性能团队推荐的一些最佳实践之后，该客户看到其 TTFB 在短短一个多月的时间内便从 3 秒大幅缩短到只有 0.6 秒（图 4）。

通过采用 Akamai 的优化措施，不仅运行缓慢的网站变得更快，就连运行速度很快的网站也变得更快了。图 5 中所示的电子商务网站每月有数百万的访问量，最近在 P75 处突破了 500 毫秒的 LCP 关键阈值，INP 达到了惊人的 50 毫秒，并且累积布局偏移 (CLS) 取得了 0.00 的满分。

通过使用 Akamai 的平台，您可以构建成熟、高度可扩展的网站，这些网站将受益于更长的正常运行时间和出色性能：无需权衡、无需妥协；尽享卓越。

读到此处，您可能希望看到我们与其他内容交付网络 (CDN) 的表现对比。然而，我们觉得很难凭良心进行这种比较，在 2025 年尤其如此。

一个主要原因是，真实用户 CWV 指标不仅取决于 CDN 的速度，还取决于网站前端和后端的编程以及它们具体的 CDN 配置，所有这些方面在不同网站之间都可能存在巨大差异。当然，您在任何平台上都可以构建运行速度快和运行速度慢的网站。

另一种方法是使用较低级别的指标，例如 TTFB。表面上，这是一个应该很容易在 CDN 之间进行比较的指标：您只需在每个 CDN 上下载一个对象、测量连接设置和请求时间……就可以了！

然而，虽然确实很容易收集这些结果，但在如今采用 HTTP/3（和 HTTP/2）及其多对象连接的环境中，这也变得越来越没有意义。对于最终用户体验（以及 LCP 等指标）而言，通过流优先级和带宽共享等高级功能来高效（重复）使用这些连接比这些连接的初始设置更加重要。

此外，很多其他技术也改变了 TTFB 的实际测量方式，包括：103 早期提示、早期数据 (0-RTT)、DNS HTTPS 记录、Speculation Rules API 等（将在“我们进行了哪些方面的改进？”部分中讨论）。

因此，在两个 CDN 上测量两个单一对象的 TTFB（一个启用了上述功能之一，另一个未启用）已经会导致截然不同的结果，而这些结果根本无法说明 CDN 的实际功能（如图 1-5 所示）。

为了证明我们的观点，我们来看一个过于相信某个基准测试的客户示例，该基准测试预测如果他们不再使用 Akamai 的产品，他们的 TTFB 就会大幅下降（图 6）。他们于 2024 年 8 月初改为使用其他解决方案，但遗憾的是他们的公开 CrUX 数据立即恶化了。

我们专注于来自 Akamai 客户的 CWV 数据，以展示我们如何影响真实用户，而不是依赖于传统的基准测试技术。不要被空口承诺所迷惑；而应该查看世界上一些最大网站的 CWV。这些网站极有可能是在 Akamai 平台上运行的，并且性能卓越。

现在，您已看到了我们过去 12 个月里进行的改进所带来的令人印象深刻的成果，那么是时候更详细地讨论这些改进的具体内容了。我们在以下方面进行了改进：

• 平台
• Akamai Image & Video Manager
• 安全解决方案
• 真实用户监控和监测能力

Akamai 的核心是我们广泛分布的平台，它能够持续将更多工作负载推向更接近最终用户的位置。这一覆盖广泛的平台让我们能够以空前的规模实施改进。

最新的改进旨在以更快的速度向真实用户交付您的内容，其中包括：

• 103 早期提示
• 早期数据 (0-RTT)
• TLS 1.3 到源站
• Speculation Rules API
• DNS 优化
• 反放大限制

对于不可缓存的资源和缓存未命中，Akamai Edge 服务器需要联系源站服务器。这会使客户端的浏览器与我们边缘服务器之间的连接在响应到达之前处于空闲状态。

借助早期提示，浏览器可以利用这段等待时间来预加载您指定的资源（例如，顶级 CSS 样式表、网页字体、徽标或关键的 JavaScript），以及预先连接到第三方域或子域。Akamai 会向您提供对这些提示的完全边缘控制权，以帮助您大幅提升渲染体验 (LCP) 的速度。

早期数据是一项强大的新功能，同时适用于基于传输控制协议 (TCP) 的 HTTP/2 和基于 QUIC 的 HTTP/3。利用此功能，浏览器可以在与 Akamai Edge 进行大多数连接时节省一个完整的网络往返时间 (RTT)。

它还可以很好地与早期提示等其他选项结合使用，尽快地将数据传输到用户的浏览器。Akamai 允许对这项强大功能固有的安全性能权衡进行精细配置。

虽然我们最大限度地利用持久连接，但有时 Akamai 确实需要建立从我们的边缘到您的源站的新 TCP 连接。我们增加了对 TLS 1.3 的支持，以避免使用 TLS 1.2 时所需要的额外 RTT。要利用这些延迟优势，请确保正确地配置您的源站。

您可以利用新的 Speculation Rules API 通过预提取或预渲染未来导航来加快多页面应用程序的运行速度。此 API 承诺在预渲染您的用户接下来可能要访问的页面时实现近乎即时的加载。

Akamai 提供了多种向您的最终用户交付推测规则的选项，因此您可以显著改进 LCP 和 CLS 等重要的 KPI。

我们的 DNS 团队已推出了下一代任播 DNS 架构的第一阶段。这项别名为“Megacloud”的计划正在进行中，我们 22 个独立集群中的 8 个已完成了转换。

Megacloud 会从更多位置公布我们的每个任播网络。该转变复杂并且经过深思熟虑，旨在确保不会影响攻击恢复能力。其结果是，所有百分位数和区域的任播 DNS 查找速度更快。

正常情况下，QUIC 的握手过程在网络上只需要 1 个 RTT 即可完成。但是，由于 Akamai 严格遵循一些行业安全要求（反映了 RFC 9000 的建议），因此很多 QUIC（以及 HTTP/3）连接实际上都需要两个 RTT。

为了解决此问题，我们将 QUIC 反放大限制从三（根据 RFC）增加为七，并且现在充分利用了 HTTP/3 的性能，只需一个 RTT 即可建立连接。

清晰的图像是现代网络的重要组成部分。要想实现出色的 LCP，图像应该快速加载，并且 Image & Video Manager 的两项新功能将帮助您实现此目标。

• SharpYUV 色度子采样：AVIF 和 HEIF 是我们提供的两种现代图像格式，它们现在使用 SharpYUV 版本的色度子采样，可以提供更好的色彩表现和更高的压缩效率。

• Cache+：利用这个新插件，您可以使用 Akamai Cloud Wrapper 来缓存 Image & Video Manager 衍生内容。它在 Cloud Wrapper 内提供了专用的缓存空间，让您可以更好地控制回收策略和缓存保留。这对性能提升非常有益，因为它可以减少不必要的重新处理，并且可确保图片在缓存中保留更长时间，从而减少了长尾未命中。

我们的大多数客户都不希望在安全性上作出妥协。但是，这不意味着他们不关心性能。

在过去 12 个月里，我们同时优化了 Akamai Bot Manager 和 Akamai Content Protector 等安全解决方案的边缘端逻辑和客户端逻辑。对于客户端库，我们进行了以下典型的 JavaScript 优化：

• 将冗长的任务拆分为更小的部分
• 删除未使用的代码
• 切换到更快的库
• 用更快的代码替换旧代码

这些优化措施减少了要通过网络发送的字节数，减少了关键路径拥塞并缩短了 JavaScript 解析和编译时间。此外，我们的安全解决方案对总阻塞时间 (TBT) 和从交互到下一次渲染的时间 (INP) 指标的影响已显著降低（例如，参见图 2）。

现在，我们了解了相关的性能指标以及各种优化措施及如何影响它们，我们可以提出的下一个问题是：“我们如何测量它们？”实现端到端可见性可能具有挑战性，尤其是使用多个云服务提供商的产品、不同的服务以及 CDN 时。

幸运的是，有一些解决方案可用于解决这些特定的操作问题，包括 Akamai mPulse 真实用户监控 (RUM) 解决方案和 CDN 可观察性中的问题。

• CWV 属性仪表板：知道您的网站运行速度缓慢是一回事，找出导致此问题的原因则更为复杂。我们推出了一些新的 mPulse 小组件来解决此问题。它们可帮助归因 CLS 问题、确定最严重和最常见的 INP 原因以及对您的 LCP 要素进行分类。

• 新指标和计时器：我们向 mPulse 中增加了很多有意思的计时器和维度。它们消除了典型的监测能力差距、减少了 RUM 噪音，让您可以更容易地深入挖掘最相关的数据。这包括 Frustrationindex、页面 CDN 缓存状态、四种新的前端计时器以及 BFCache 信息。

• 未归因的导航开销 (UNO)：这个新的计时器会累计导航过程中所有未被其他计时器计算在内的“未知”及“额外”时间跨度。这可能包括浏览器延迟、磁盘访问时间、跨源站限制带来的隐藏时间等。此指标可帮助弥补差距并发现可能被忽视的问题。

• 我们对 Akamai DataStream 2 进行了修正，它现在为对性能感兴趣的用户提供了更多相关数据点：

  • TLS 早期数据和 103 早期提示字段支持
  • Akamai EdgeWorkers 支持
  • TrafficPeak 目的地支持

• 导览列：新的导览列功能让您可以实时监测内容交付过程中影响性能的情况和错误状况。

• 通用媒体客户端数据 (CMCD)：从流式传输视频、音乐或游戏等内容的设备中收集性能数据和使用情况指标，对于衡量流式传输性能至关重要。识别和缓解：

  • 缓冲事件
  • 缓慢的启动速度
  • 播放质量问题
  • 错误率
  • 吞吐量

在过去 12 个月里，我们推出了一些改进措施，这些措施不仅在理论上，而且对真实用户来说，能够切实地提升现代应用程序的速度。这些更改的效果在 CrUX 数据中屡次得到清晰验证，不仅显著改进了 CWV 结果，还改善了最终用户体验和梦寐以求的 Google 搜索引擎排名。

虽然我们对很多改进结果感到满意，但我们的团队始终有机会进一步缩短时间——当然，这需要兼顾安全性、可扩展性和可用性。

我们计划在未来几周、几个月和几年里推出更多优化措施。敬请期待，我们将携手迈向更快的未来。