当我们 宣布量子项目 时，我们谈论了用户如何从我们对“性能提升”的关注中获益……这些提升将会是如此显著，以至于你的整个网络体验都会感觉不同。”

是什么让性能工作如此具有挑战性，以及为什么从一开始就将用户纳入进来如此重要？

性能——至少可以说是一个有争议的话题！

人们对性能作为 UX 问题的认识通常始于负面体验——当事情变得缓慢或无法按预期工作时。事实上，良好的性能已经成为一个基本要求，是每个人对在线产品或服务的预期。出色的性能很快将成为新的基准参考点。

另一个问题是，对性能有不同的看法。对于用户来说，性能就是他们的体验，而且很多时候是不具体的。对他们来说，对良好性能的感知可以从“这太快了”到“慢！”，从“哇！”到“不行！”。对于工程师来说，性能就是数字和流程。在代码中收集数据的探针通常测量管道中一项特定任务。测量和跟踪垃圾回收 (GC) 等功能使工程师能够迅速应对数据回归，并致力于修复根本原因。

这就是为什么在用户体验和工程缓解工作之间可能会存在脱节。我们测量垃圾回收，但它通常是在没有上下文的情况下测量的，例如，它是在页面加载期间运行，是在用户与网站交互时运行，还是在事件队列空闲时间运行。通常，GC 在预算范围内，这意味着用户几乎不会感知到它。更一般地说，我们用探针测量的特定方面可能很难映射到用户体验的非特定性能体验。

定义技术性能和感知性能

为了描述一种针对用户优化性能的方法，让我们首先定义性能的含义。对我们来说，性能有两方面：**技术性能和感知性能**。

在**技术性能**下，我们包括可以在浏览器中测量的东西：页面元素渲染需要多长时间、解析 JavaScript 的速度，以及——通常更重要的是要理解——某些事情有多慢。技术性能可以被测量，由此产生的数据可以用于调查性能问题。技术性能代表了工程师的观点。

另一方面，还有用户如何体验性能。当用户谈论他们浏览器的性能时，他们谈论的是**感知性能或“体验质量”** (QoE)。用户以任何可感知、可识别和可命名的产品特征来表达 QoE。在 QoE 理论中，这些被称为 QoE 特征。我们可以假设这些特征与影响产品技术性能的产品因素相关，即 QoE 因素，但这并不一定如此。

一种很有前景的用户感知性能优化方法是确定对 QoE 特征影响最大的那些因素，并专注于优化它们的 технической性能.

理解感知

优化量子感知性能的第一步是了解人类感知是如何工作的。我们在这里不会详细介绍，但重要的是要知道，存在我们可以利用的持续时间感知阈值。最突出的与 Web 交互相关的阈值是 由雅各布·尼尔森 在 1990 年代定义的，即使在今天，它们也为像 RAIL 这样的以用户为中心的性能模型提供参考。遵循尼尔森的阈值可以让我们首先对浏览器引擎执行某些任务的可用预算进行良好的估计。

通过我们的 用户研究团队，我们正在验证和调查这些感知阈值，以适应现代网络内容。我们正在与用户进行实验，既在实验室中进行，也在远程进行。当然，这只有在获得用户同意的情况下才会进行，每个人都可以随时选择加入或退出这些研究。 借助像 Shield 这样的工具，我们进行了一系列实验，使我们能够了解性能以及如何为用户改进性能。

然而，了解感知阈值和相应的预算只是一个重要的第一步。接下来，我们将更详细地介绍如何在我们的新浏览器引擎开发过程中使用数据驱动的方法来进行基准测试和优化性能。

感知 Web 性能的三个支柱

优化浏览器引擎的感知性能的挑战在于，从网络获取数据到我们的屏幕中 涉及许多组件。所有这些组件都可能对感知性能以及底层感知阈值产生影响。但是，用户不知道这种结构和引擎。从他们的角度来看，我们可以定义用户在 Web 上感知性能的三大支柱：**页面加载**、**流畅度**和**响应速度**。

• **页面加载**：这是人们每次加载新页面时都会注意到的事情。用户关心快速页面加载，我们已经在用户研究中发现，这通常是用户判断浏览器性能好坏的方式。定义页面加载期间感知预算的关键事件是：对用户新页面请求的即时响应，也称为“首次渲染”或“首次非空白绘制”，以及所有重要元素显示的时刻，目前讨论的是 英雄元素时序。
• **流畅度**：滚动和平移在现代网站上已经成为具有挑战性的活动，包括无限滚动、视差效果和动态粘性元素。动画在与页面交互时创造了更好的用户体验。我们的用户希望享受滚动网页和网页动画的流畅体验，无论是在社交媒体页面上还是在购买最新的小工具时。如今，人们通常将流畅度称为“始终 60 fps”。
• **响应速度**：除了滚动和平移之外，网站上另一大类用户交互是鼠标、触摸和键盘输入。随着现代网络服务创造了类似原生应用程序的体验，用户对网络服务的期望更高，基于他们对笔记本电脑和台式电脑上原生应用程序的期望。用户已经对输入延迟很敏感，因此我们目前正在研究 100 毫秒的理想最大延迟。

针对整个 Web 的优化

但是我们如何为整个 Web 优化这三个支柱呢？这比优化单个网络服务的性能要大得多。在构建 Firefox 时，我们面临着优化浏览器引擎的挑战，而不知道我们的用户访问哪些页面或他们在 Web 上做了什么，这是因为我们致力于保护用户隐私。这也限制了我们为特定网站或特定用户任务收集数据。但是，我们希望为尽可能多的用户和站点创造最佳的体验质量。

首先，我们决定专注于当前 Web 用户最喜欢的几种内容类型。这些类别是

• 搜索（例如雅虎搜索、谷歌、必应）
• 生产力（例如雅虎邮箱、Gmail、Outlook、GSuite）
• 社交（例如 Facebook、LinkedIn、Twitter、Reddit）
• 媒体（例如 YouTube、Netflix、SoundCloud、亚马逊视频）
• 电子商务（例如 eBay 或亚马逊）
• 新闻与参考（例如纽约时报、BBC、维基百科）

我们的目标是从这些初始类别及其内部最常用的站点中学习，并将我们对改进工作的扩展到其他类别，随着时间的推移。但是我们现在如何将技术性能与感知性能相匹配，以及如何修复技术性能问题以改善感知性能呢？

优化浏览器引擎的数据驱动方法

我们这里方法的目标是利用对用户重要的内容，并将这些知识应用于在引擎中实现技术影响。在定义了上述基础知识之后，我们优化引擎的迭代方法如下

1. 识别：基于关注的类别集合，我们指定了页面加载、流畅度和响应速度超出性能预算并对感知性能产生负面影响的场景。
2. 基准：我们为识别出的场景定义测试用例，以便在我们的基准测试平台中使它们变得可重复和可量化。
3. 性能概况：我们记录和分析性能概况，以创建对浏览器引擎中发生情况的详细视图，并指导工程师识别和修复技术根本原因。

识别超出性能预算的场景

识别这些场景的输入来自不同的来源。它们要么由用户研究的结果告知，要么可以通过错误或用户反馈报告。以下列举两种此类场景的示例

• 场景：浏览器启动
• 类别：页面加载的特殊情况
• 性能预算：首次绘制 1000 毫秒，英雄元素 1500 毫秒
• 描述：通过单击图标打开浏览器 > 等待浏览器以最大化窗口完全加载
• 测量指标：首次绘制：浏览器窗口出现在桌面上，英雄元素：“搜索”内容窗口搜索框中的占位符

• 场景：在 Facebook 上打开聊天窗口
• 类别：响应速度
• 性能预算：150 毫秒
• 描述：登录 Facebook > 等待主页完全加载 > 单击聊天面板中的姓名以打开聊天窗口
• 测量指标：从鼠标单击输入事件到聊天窗口显示在屏幕上的时间

基准

我们构建了不同的测试平台，使我们能够获得有效且可重复的结果，以便为每个场景创建基线，并且能够随着时间的推移跟踪改进。 Talos 是一个由 Python 驱动的性能测试框架，它在许多其他测试中，对 浏览器启动 和 页面加载 定义了一组测试。它最近已更新以匹配新要求，并更接近用户感知测量事件，例如首次绘制。

Hasal 另一方面，专注于响应速度和流畅度的基准。它运行一组定义的脚本，执行定义的场景（例如上述“打开聊天窗口”场景），并通过分析交互过程中捕获的视频提取所需的计时数据。

此外，仍然存在大量非自动化的手动测试，尤其是在对新的场景进行脚本化自动测试之前，用于第一轮基准测试。因此，我们使用 HDMI 采集卡并手动逐帧分析录制的视频。

所有这些测试平台都为我们提供了数据，说明识别出的场景在超出其各自感知预算方面有多么重要。定期（每周一次或更频繁）对关键场景（例如浏览器启动）运行基准测试还可以跟踪改进，并在改进将场景移动到感知预算中时提供良好的方向。

性能概况

现在，我们已经定义了场景并了解了创建良好用户体验需要多少改进，最后一步是使工程师能够实现这些改进。工程师查看浏览器引擎中性能问题的方式是通过性能概况。性能概况是在特定用户任务（例如我们定义的场景之一）期间浏览器引擎中发生情况的快照。

使用 Gecko Profiler 的性能概况。该概况显示了 Gecko 的主线程、四个内容线程和合成器主线程。以下是调用堆栈。

概况由包含跟踪标记的时间轴、不同的线程时间轴和调用树组成。时间轴由几行组成，这些行表示跟踪标记（彩色段）方面的有趣事件。使用时间轴，您还可以放大以获取标记区域的更多详细信息。线程时间轴显示了已分析线程的列表，例如 Gecko 的主线程、四个内容进程线程 (多进程带来的好处)，以及 合成器进程 的主线程，如上图所示。x 轴与上面的时间轴同步，y 轴显示了给定时间点的堆栈深度。最后，调用树显示了在给定时间范围内按“运行时间”组织的收集到的样本。

需要一些经验才能阅读这些性能概况并将它们转换为操作。但是，由于它们将关键用户场景直接映射到技术性能，因此性能概况是根据用户关心的问题改进浏览器引擎的良好工具。这里的挑战是识别根本原因以广泛提高性能，而不是专注于特定网站和单个错误。这也是我们专注于页面类别而不是一组初始网站的原因。

有关性能概况的深入信息，这里有一篇关于性能概况的文章和 Ehsan Akhgari 的演讲。我们正在 不断改进性能分析器插件，它现在是用 React/Redux 编写的。

迭代测试和性能分析

对上述场景进行基准测试和性能分析的第一轮可以帮助我们从识别用户性能问题转变为修复浏览器引擎中的这些问题。但是，只有迭代测试和性能分析才能确保在代码中修复的补丁也能带来预期的性能预算方面的收益。

此外，迭代基准测试还有助于识别补丁对其他关键场景的影响。查看不同的性能概况并捕获可比较的交互或页面加载场景实际上会导致修复根本原因。通过修复根本原因，而不是专注于一次性案例，我们预计能够提高 QoE 并使整个网站和活动类别受益。

使用 Telemetry 进行持续性能监控

最终，我们希望超越特定的一组网页类别，关注整个 Web。我们还想超越手动测试，因为这很昂贵且耗时。我们希望应用从最初的数据驱动方法中获得的知识，并将它扩展到通过 Telemetry 监控整个用户群的性能。

我们最近在 Telemetry 系统中添加了探针，这些探针将帮助我们跟踪对用户重要的事件，这些事件在所有网站中都有，例如 页面加载期间的首次非空白绘制。随着时间的推移，我们将有意义地扩展探针集。Google Chrome 团队及其 渐进式 Web 指标 已经做出了定义和包含更接近用户感知的探针的良好尝试。

页面加载和页面交互期间的渐进式 Web 指标的可视化。上面的字段显示用户交互级别以及与技术指标相关的关键交互。

如开头所述，对于用户来说，性能是基本要素，是他们期望的。在本文中，我们探讨了：如何捕获感知性能中的问题，如何使用基准来衡量性能问题的严重程度，以及如何通过查看性能概况来修复问题。

除了当前性能方法的范围之外，还有一个更有趣的问题：改进的性能是否会导致浏览器使用量增加或用户使用浏览器方式的改变？性能改进是否可以提高用户参与度？

但是，这些主题还需要更多研究——并且，在某个时候，将成为另一篇博文的主题。

同时，如果您现在有兴趣关注性能改进并体验 Firefox 浏览器的增强性能，请下载并安装最新的 Firefox Nightly 版本 并看看您对它的 QoE 的看法。