对于任何软件来说，最大的挑战之一是确定更改如何影响现实世界中的用户体验。无论是视频编辑软件的处理速度，还是浏览体验的流畅度，在受控的实验室环境中进行测试只能告诉你这么多。虽然本地实验可以提供大量的指标，但这些指标的改进可能不会转化为更好的用户体验。

对于像 Firefox 这样的运行第三方代码的复杂客户端软件来说，这可能尤其具有挑战性，这也是我们与其他 Web 浏览器一起开展 Speedometer 3 工作 的一大原因。我们的目标是构建模拟现实世界用户体验的性能测试，以便浏览器拥有更好的工具来推动对真实网页上真实用户的改进。虽然很容易看到，由于这项工作，Firefox 在今年全年的基准测试都得到了改进，但我们真正关心的是，这些成果对我们的用户来说有多大意义。

为了衡量用户体验，Firefox 收集了大量与页面加载、响应速度、启动和其他浏览器性能方面相关的匿名计时指标。在保持最高隐私标准的同时收集数据可能具有挑战性。例如，由于我们依赖于汇总指标，因此我们无法从任何特定网站精确定位数据。但也许更具挑战性的是分析收集到的数据并得出可操作的结论。在未来，我们将更多地讨论这些挑战以及我们如何解决这些挑战，但在本文中，我们想分享一下，在今年全年，我们用户体验浏览器的某些基本指标是如何改进的。

让我们从页面加载开始。 首次内容绘制 (FCP) 比 `onload` 事件更能反映性能体验。我们正在跟踪从网络接收第一个字节到 FCP 所花费的时间。这告诉我们，我们以多快的速度向用户提供页面正在成功加载的反馈，因此它是了解用户体验的关键指标。虽然这很大程度上取决于网页本身，但如果浏览器在整体上提高了性能，我们预计这个数字会下降。

图片 1 - 从响应开始到首次内容绘制的中位时间（毫秒）

我们可以看到，这段时间从今年年初的约 250 毫秒改善到 10 月的 215 毫秒。这意味着用户在页面加载方面的反馈速度比年初快了近 15%。重要的是要注意，这一切都是优化工作的成果，而这些优化工作甚至没有明确地针对页面加载。

为了了解这种改进来自哪里，让我们看一下另一个计时数据：页面加载期间执行 JavaScript 代码所花费的时间。在这里，我们将查看第 95 个百分位数，它代表着最重的 JS 页面，并突出了我们消除用户摩擦的一个巨大机会。

图片 2 - 页面加载期间 JS 执行时间的第 95 个百分位数（毫秒）

这表明，第 95 个百分位数从今年初的约 1560 毫秒改善到 10 月的约 1260 毫秒。这代表了 300 毫秒的显著改进，或者说近 20%，并且很可能是 FCP 时间减少的重要原因。这是有道理的，因为 Speedometer 3 工作导致了对 SpiderMonkey JavaScript 引擎（另一篇文章的内容）的重大优化。

我们还想了解页面加载后页面的响应速度。例如，当我写这篇博文时，在键盘上打字的响应速度有多快！我们在这里收集的主要指标是“按键出现延迟”；从在键盘上按下键到结果呈现在屏幕上的时间。将一些文本呈现到屏幕上可能听起来很简单，但要做到这一点需要做很多事情——尤其是在网页运行主线程 JavaScript 来响应按键事件时。大多数打字都非常快，主要受硬件限制（例如显示器的刷新率），但如果不快就会非常令人沮丧。这意味着抑制最坏的情况非常重要，所以我们再次看一下第 95 个百分位数。

图片 3 - 按键出现延迟的第 95 个百分位数

我们再次看到可测量的改进。第 95 个百分位数在今年的大部分时间里都徘徊在 65 毫秒左右，在 8 月发布 Firefox 116 和 117 版本后降至 59 毫秒以下。对最慢按键的 10% 的改进意味着用户体验到更多即时反馈，并且在打字时更少的干扰。

我们对在遥测数据中看到的改进感到鼓舞，我们相信我们今年的努力对 Firefox 用户产生了积极影响。我们还有很多优化正在进行中，我们将在以后的文章中分享有关这些优化以及我们整体进展的更多详细信息。