发布时间：2025 年 4 月 4 日
解决实际性能问题意味着要缩小开发环境与用户的多样化性能体验之间的差距。在本文中，我们将介绍 Chrome 开发者工具中的新功能，这些功能可帮助您根据真实数据（而非猜测）做出更多性能调试决策。
调整预期
从 Chrome 134 开始，开发者工具中新增了CPU 节流校准工具，可消除选择正确 CPU 节流级别的不确定性。运行一次校准后，DevTools 会为您生成特定于开发机的“低端移动设备”和“中端移动设备”节流预设。
网站性能工作中的一个常见差异是，作为开发者，我们通常在速度较快的桌面设备上构建网站，而许多用户使用的是性能较为一般般的移动设备。如果性能问题仅在 CPU 速度较慢的设备上出现，则很难进行跟踪。
黄金标准是在真实移动设备上进行远程调试，但在近十年的时间里，Chrome 还支持CPU 节流，以便在开发期间快速轻松地迭代。
但您应该选择哪个 CPU 节流级别？4 倍？20 倍？如何确定哪种设备类型最符合您知道的访问您网站的设备类型？无论您使用的是高端工作站，还是外出时使用 8 年前的 Chromebook，您机器的速度如何影响这一决定？
节流校准流程
打开“性能”面板后，您会在“环境”设置中看到一个下拉菜单，用于设置 CPU 节流级别。如果您之前未运行过校准，则会在下拉菜单的“已校准的预设”下看到两个已停用的选项，并在底部看到一个校准…选项。
选择此选项后，您会进入设置中的 CPU 节流预设（您也可以直接前往该位置）。
- 点击校准按钮
- 当系统警告您即将短暂离开当前页面时，点击继续
- 系统会运行一个快速基准测试来衡量您当前机器的速度，然后校准便会完成
节流选项现在将填充针对低端和中端设备校准的预设。
这两个预设应该足以满足大多数开发用例，我们通常建议使用“中端”预设，以匹配网络上常见的“典型”移动设备。如果您知道许多用户的设备运行速度更慢，或者性能问题通常只会出现在这些用户的设备上，则“低级别”选项的速度应该足够慢，以捕获低端设备的长尾。
最后，如果您认为校准出了问题，或者本地计算机发生了某种变化，可以随时通过节流下拉菜单或在设置中重新校准，系统会重新运行基准测试并更新预设。
开发者工具中的 CPU 节流功能的运作方式
如果您曾经好奇过 DevTools 中的 CPU 节流功能如何运作，那么您会发现其原理相对简单。当您为标签页开启节流功能时，Chrome 会启动一个单独的节流线程，该线程会中断并暂停标签页的主线程，以便频繁进行短时间的突发操作。目的是让主线程总共挂起足够长的时间，以使任何给定任务的持续时间增加到节流因子。
例如，在 CPU 节流 4 倍的情况下，主线程最终会在约 75% 的时间内处于暂停状态，这会导致任何主线程工作完成所需的时间增加到原来的 4 倍。
这种方法的好处在于，它对 Chrome 的其余部分来说大多是透明的；无需任何专用代码即可减慢 JavaScript 或布局速度，或减慢浏览器需要执行的许多其他类型的工作。由于线程本身只能执行一小部分时间，因此主线程上的所有工作都需要更长时间。
当 CPU 节流像真实移动设备一样运行时
因此，CPU 节流可以很好地模拟许多类型的移动设备 CPU 绑定工作。例如，如果某个互动触发了 JavaScript 和布局，那么其执行方式很可能与在移动设备上运行的方式非常相似。
假设有一个任务由点击按钮触发，该任务会运行 JavaScript 以向 DOM 添加新元素，然后需要浏览器运行样式和布局计算以定位新内容：
使用校准的“中端移动设备”CPU 节流预设（在此开发机上为 3.7 倍），交互看起来非常相似，但时长显著增加，成为一项长时间任务：
在真实的中端设备上使用远程调试测试相同的互动，无论是互动轨迹的形状还是时长，都会得到非常相似的结果。由于此任务在主线程中主要受 CPU 限制（执行网页的 JavaScript 代码以及 Chrome 的样式和布局代码），因此经过校准的节流功能可准确再现真实的移动设备性能：
您可能仍希望在真实移动设备上进行测试的情况
虽然非常有用，但 CPU 节流无法模拟移动硬件的所有方面。在手机上，磁盘速度较慢、内存带宽更有限，并且温控调节功能随时都可能启用，以降低执行速度。
一个常见的节流限制涉及 GPU 密集型工作。移动设备 GPU 和桌面设备 GPU 在架构上有所不同，Chrome 会在与网页主线程不同的进程中运行 GPU 操作。因此，DevTools 的 CPU 节流不会影响 GPU 进程（这样做是最好的，因为这会影响 DevTools 本身和浏览器的其余部分的响应能力）。
复杂的绘制、合成和效果繁重的样式是常见的性能问题，在开发机上看起来可能没问题，但在移动设备上却会意外地运行缓慢。而且，在开发机上尝试重新创建问题时，很难发现是否存在问题。
考虑与前面相同的互动（点击并向 DOM 添加许多元素），只不过这次，新元素的样式使用了过多的 GPU 密集型阴影和模糊滤镜。
互动开始时的形状和时长看起来很相似，但在互动结束时，有一个长时间的新主线程绘制，用于添加效果：
在真实的中端手机上，交互的主线程部分看起来与模拟的部分非常相似，包括额外的绘制，但在交互结果显示在屏幕上之前，一个未知的 GPU 进程似乎要执行大量工作：
GPU 工作会将互动时间再延长 300 毫秒，而对于笔记本电脑 GPU，这项工作几乎不存在，即使启用了（主线程）CPU 节流也是如此。
还有一些其他情况也存在严重的模拟缺点，例如深层依赖项页面加载，其中模拟的网络节流、进程间通信以及访问磁盘和内存缓存之间存在相互作用。
请务必在某个时间点在真实移动设备上进行测试。如果您无法在实验室的桌面机器上重现现场数据显示会影响移动用户的问题，请务必尝试使用真实设备进行远程调试，看看是否有您忽略的差异。
更多以数据为依据的调试改进
我们最近还推出了一些其他新功能，可帮助您更轻松地根据真实用户来设置调试设置和做出决策。
如果您启用了实测数据，效果面板会根据 Chrome 用户体验报告 (CrUX) 衡量到的第 75 百分位用户提供有关节流的建议，如果您在本地测量的指标与实测数据不一致，实时指标视图会向您发出提醒。一篇关于将真实的 Core Web Vitals 数据导入到开发者工具的早期文章详细介绍了这一点。
新推出的一项功能是，如果轨迹中衡量的指标与用户在实际环境中的体验不符，侧边栏中的“性能”面板数据分析现在还会向您发出提醒。
启用实测数据后，您还可以使用第 75 个百分位数的 Core Web Vitals 来帮助确定边栏中显示数据分析的顺序。例如，如果您的用户通常具有出色的 Largest Contentful Paint (LCP) 但 Interaction to Next Paint (INP) 较差，有助于提高 INP 的分析通常会显示在列表顶部。
最后，如果您曾经在多个轨迹之间来回切换，或者从磁盘加载轨迹，则可能很难准确记住您在每个轨迹中使用了哪些移动设备模拟和节流设置。性能面板顶部的轨迹选择 下拉菜单现在会显示每个轨迹的模拟信息。
停止、校准和聆听
最终，我们需要根据实际情况做出调试决策：首先从分析和用户报告中获取实测数据来查找问题，然后在实验室中重现这些用户体验以进行诊断。这些新增的开发者工具应该有助于简化该过程。
针对差异较大的现场和实验室体验的 CPU 节流校准和提醒有助于降低您是否走在正确道路上的不确定性，并让您能够更一致地近似真实世界中的性能。通过消除配置方面的猜测并突出显示可能存在的差异，DevTools 旨在帮助您将更多时间集中于解决影响用户的实际性能问题。
您有关于进一步改进或新功能建议的想法吗？请告诉我们！