英文：林·克拉克翻译：

人们注意到，速度再次变快了。

在过去的七个月里，我们使用 Rust 和 Servo 的部件快速更换了引擎的主要部件。 此外，还有一个代码衍生的问题会显着或微妙地影响浏览器性能。

我们称之为“重生”，第一个常规版本将于明天发布。

但这并不意味着我们的工作已经完成，也不意味着未来的速度和响应能力不会进一步提高。

那么，让我们看看它是如何再次变快的，以及在哪些部分变快了。

使用-作为基础

为了加快速度，我们利用了过去 10 年中硬件的变化。

我们不是第一个这样做的。 与首次推出时相比，它速度更快、响应更灵敏。 原因之一是我们的工程师看到了硬件的变化并更好地利用了它。

一种新型CPU开始流行。 这些 CPU 具有多个核心，这意味着它们可以独立完成任务，也可以并行完成任务。

这可能会变得棘手。 使用 CPU 的并行性可能会引入难以发现和调试的微妙错误。 例如，如果两个内核需要递增内存中的同一数组火狐浏览器下，如果不小心，一个内核很容易覆盖另一个内核。

避免这些各种错误的一个非常简单的方法是仅确保两个事物（函数）在不共享内存的情况下运行 - 将程序中的大型任务拆分为与（的子任务）配合，这就是粒度并行。

在浏览器中，这些颗粒相当容易找到，并且每个选项卡都是独立工作的。 该网页周围有一些东西——浏览器——可以独立处理。

这样页面就可以并发工作而不会互相阻塞。 如果后台选项卡中有长时间运行的脚本，它不会阻止前台选项卡的工作。

这是工程师看到的机会，我们也看到了，但我们的道路更加坎坷。 从我们现有的代码库中，我们需要规划如何拆分代码库以利用多个核心。

一段时间后，我们实施了它。 通过这个“电解”项目的实施，我们最终实现了默认为所有用户启用多处理。 （浏览器）已经使用了粗粒度并行性，甚至比其他一些项目更好。

电解

电解为量子项目奠定了基础，引入了类似的多进程架构。 因为这是一个突破性的变化，我们在 2016 年向一小群用户慢慢引入它，进行测试，然后在 2017 年中期向所有用户推出。

量子合成器

量子合成器将合成器移动到自己的过程中。 这里最大的成功是使其更加稳定。 拥有一个单独的进程意味着如果图形驱动程序崩溃，它不仅不会使所有页面崩溃，而且这个单独的进程使其响应更快。

DOM

即使您在核心之间分割内容窗口，并为每个核心提供一个主线程，主线程仍然有很多工作要做。 其中一些比其他更重要。 例如，响应按键比运行垃圾收集更重要。 DOM 为我们提供了一种确定这些任务优先级的方法。 这使得它更具响应性。 这项工作的大部分已经实施，但我们仍然计划采取进一步的措施，称为抢占式调度。

充分利用硬件的精细并行性

然而，当我们展望未来时，我们需要比并行更进一步。

- 并行可以更好地利用硬件......但没有充分利用它。 当您将网页分配给不同的核心时，某些核心可能无法分配工作。 所以这些核心闲置。 同时，如果CPU是单核的话，新的核心启动新页面的时间会更长。

如果能够使用所有核心来处理新页面，那就太好了。 这样您就可以更快地完成工作。

但如果使用-，则无法将任何任务从一个核心分离到另一个核心，任务之间没有边界。

通过精细并行，您可以将较大的任务分解为较小的单元，然后将其发送到不同的内核进行处理。 例如，如果你有一个类似的网站，你可以将其拆分为不同的固定模块，并将它们发送到不同的内核进行处理。

这不仅有助于解决粗粒度并行性等延迟问题。 它还有助于提高速度。 页面加载速度会更快，因为计算被分解到不同的计算核心中。 添加更多计算核心时，页面加载速度会更快。

所以我们认为这是未来，但目前还不完全清楚如何实现这一目标。 由于要使这种细粒度并行性更快通常需要在内核之间共享内存。 但这会带来我们之前谈到的那些数据竞争问题。

但我们知道浏览器必须进行这种转变，因此我们开始投资于研究。 我们创建了一种不存在这些数据竞争问题的语言 - Rust。 然后，我们创建了一个浏览器引擎 Servo，以利用这种细粒度的并行性。 通过这一点，我们已经证明这可以发挥作用并减少错误，同时加快速度。

CSS（也称为 Stylo）

借助 Stylo，渲染 CSS 样式的工作在所有 CPU 核心上完全并行。 Stylo 使用一种称为“工作窃取（work）”的技术来有效地在核心之间分配工作，使每个核心保持忙碌。 通过这种技术，可以获得线性加速效果。 您可以使用您拥有的所有核心来分配 CSS 样式渲染的时间。

（有特点）

另一件硬件是高度并行化的 GPU，它有数百或数千个核心。 即便如此，我们仍然需要保证GPU的多核尽可能保持工作，以提高效率，这就是所做的事情。

计划于 2018 年推出，它将充分利用现代 GPU。 同时我们也从另一个角度来看待这个问题。 项目修改了现有的图层系统以支持批量渲染。 通过优化当前 GPU 使用模式火狐浏览器下，我们取得了立竿见影的效果。

我们认为渲染管道的其他部分也可以从这种细粒度并行性中受益。 在接下来的几个月里，我们将仔细研究这些技术还可以用在哪些地方。

我们承诺会变得更快并且永远不会变慢

除了我们必须做出的这些重大架构更改之外，一些性能错误还在我们没有注意到的情况下进入了代码库。

所以我们构建了的另一部分来修复它，它会发现这些问题，然后团队会解决这些问题。

流动

Flow的团队很强，但是他们不关注具体子项目的进展。 他们主要关注一些特殊的场景，例如社交媒体提要的加载，并研究如何使加载更快。

Flow 给我们带来了巨大的性能优势。 在此过程中，我们还开发了工具和特定流程，以便更轻松地查找和跟踪类似问题。

流现在怎么样了？

我们在这一过程中非常成功 - 一次识别并专注于一个关键案例 - 并将其纳入我们工作流程的一部分。 为了做到这一点，我们将改进我们的工具，因此我们不再需要专门的团队来解决特定问题，而是需要更多的工程师来追踪这些问题并解决它们。

但这种方法有一个问题。 当我们优化一个用例时，我们需要取消优化另一个用例。 为了防止这种情况，我们添加了许多新的跟踪，包括改进的用于运行性能测试的 CI 自动化、用于用户体验的遥测跟踪以及错误中的回归管理。 通过这些举措，我们期望变得越来越好。

明天只是开始

明天对我们来说是重要的一天。 在过去的一年里

最新软件下载

，我们一直致力于提高速度，但这仅仅是开始。

未来，我们将继续发布新的改进并与您分享。

请访问试用或确保您获得最新更新。