在 Chrome 102 中，您会在开发者工具中看到一个新的实验性面板：Performance Insights。在这篇博文中，我们不仅会讨论新组建小组的原因，还会讨论我们面临的技术难题，以及我们在此过程中做出的决策。
为什么要构建另一个面板？
（如果您尚未看到它，不妨观看我们发布的视频，了解为什么要构建效果数据分析面板，以及如何通过它获取有关网站效果的富有实用价值的分析洞见。）
如果您希望在一个位置查看网站的所有数据，现有的效果面板是一项很好的资源，但我们认为这可能会有点不堪重负。如果你不是性能专家，就很难确切地知道该寻找什么内容以及录音中的哪些部分是相关的。
进入 Insights 面板，您仍然可以查看跟踪记录的时间轴并检查数据，但也得到了一份便捷列表，其中列出了开发者工具认为值得深入研究的主要“数据分析”的内容。数据分析会识别各种问题，例如呈现阻塞请求、布局偏移和耗时较长的任务等等，这些问题都会对您网站的网页加载性能，尤其是网站的核心网页指标 (CWV) 得分产生负面影响。除了标记问题之外，效果数据分析还会为您提供切实可行的建议来提高 CWV 得分，并提供指向其他资源和文档的链接。
此面板尚处于实验阶段，我们期待您的反馈！如果您遇到任何错误，或者有您认为对改善网站性能有帮助的功能请求，请告诉我们。
我们如何构建效果数据分析
与开发者工具的其余部分一样，我们在 TypeScript 中构建了性能数据分析，并使用由 lit-html 提供支持的 Web 组件来构建界面。性能数据分析的不同之处在于，主界面是 HTML canvas 元素，时间轴会绘制在此画布上。很多复杂工作都源于管理此画布：不仅要在正确的位置绘制适当的细节，还要管理鼠标事件（例如：用户点击画布的何处？他们是否点击了我们绘制的事件？），并确保我们有效地重新渲染画布。
在单张画布上呈现多条轨道
对于某个网站，我们需要呈现多个“轨道”，每个轨道代表一种不同的数据类别。例如，“数据分析”面板在默认情况下会显示三条轨道：
随着我们不断在面板中推出功能，预计会添加更多轨道。
我们最初的想法是，让每个轨道渲染自己的 <canvas>，以便让主视图成为多个垂直堆叠的画布元素。这样可以简化轨道级别的渲染，因为每个轨道都可以单独渲染，不存在轨道超出其边界渲染的风险。但遗憾的是，这种方法有两个主要问题：
canvas 元素的（重新）渲染开销很高；拥有多个画布比使用一个画布的成本更高，即使画布较大也是如此。渲染跨多个轨道的任何叠加层（例如，用于标记 FCP 时间等事件的垂直线）都会变得很复杂：我们必须渲染到多个画布上，并确保它们全部渲染在一起并正确对齐。
为整个界面使用一个 canvas 意味着我们需要弄清楚如何确保每个轨道以正确的坐标渲染，并且不会溢出到另一个轨道。例如，如果特定轨道的高度为 100 像素，我们就不能允许它渲染高度为 120 像素的部分，并使其渗透到其下方的轨道中。为解决此问题，我们可以使用 clip。在渲染每个轨迹之前，我们先绘制一个矩形来代表可见轨迹窗口。这样可确保在这些边界之外绘制的任何路径都会被画布裁剪。
canvasContext.beginPath();
canvasContext.rect(
trackVisibleWindow.x, trackVisibleWindow.y, trackVisibleWindow.width, trackVisibleWindow.height);
canvasContext.clip();
此外，我们也不希望每个轨道都知道其在垂直方向的位置：每个轨道应像渲染在 (0, 0) 时进行自我渲染，我们还有一个更高级别的组件（我们称之为 TrackManager）来管理整体轨道位置。这可以使用 translate 来完成，它会按指定的 (x, y) 位置平移画布。例如：
canvasContext.translate(0, 10); // Translate by 10px in the y direction
canvasContext.rect(0, 0, 10, 10); // draw a rectangle at (0, 0) that’s 10px high and wide
尽管 rect 代码将 0, 0 设置为位置，但应用的总体平移会导致矩形以 0, 10 呈现。这样，我们就可以像在 (0, 0) 处进行渲染，让轨道管理器在渲染每个轨道时进行平移，从而确保每个轨道正确渲染到前一个轨道之外。
赛道和精彩集锦的屏幕外画布
画布渲染的成本相对较高，我们希望确保“数据分析”面板在您使用它时保持流畅且响应迅速。有时，您无法避免重新渲染整个画布：例如，如果您更改缩放级别，我们必须重新开始渲染所有内容。画布重新渲染的开销特别大，因为您不能只重新渲染其中的一小部分；您需要擦除整个画布，然后重新绘制。这与 DOM 重新渲染不同，在重新渲染中，工具可以计算出所需的最少工作量，并且不会移除所有内容并重新开始。
视觉问题的一个方面凸显了出来。当您将鼠标悬停在面板中的指标上时，我们会在时间轴上突出显示这些指标；同样，如果您将鼠标悬停在指定事件的数据分析上，我们会在该事件周围绘制蓝色边框。
该功能的实现方式是：检测某个元素上的鼠标移动会触发突出显示的内容，然后将该突出显示内容直接绘制到主画布上。这就出现了问题，当我们必须移除突出显示效果时：唯一的选择是重新绘制所有内容！不可能只是重新绘制突出显示区域所在的区域（并非没有进行巨大的建筑更改），而是仅仅因为我们想要移除一个项目周围的蓝色边框，就重新绘制了整个画布，这让人感觉有点过度。如果您在不同内容上快速移动鼠标以快速连续触发多个高亮显示，它也会出现视觉延迟。
为了解决此问题，我们将界面拆分成两个“离屏”画布：用于渲染轨迹的“主”画布和用于绘制高光的“突出显示”画布。然后，我们通过将这些画布复制到用户在屏幕上看到的单个画布上进行渲染。我们可以对画布上下文使用 drawImage 方法，该方法可以将其他画布作为来源。
也就是说，移除突出显示效果不会导致系统重新绘制主画布：我们可以先清除屏幕上的画布，然后复制主画布到可见画布上。复制画布的成本很低，而绘图的成本很高；因此，通过将高光移到单独的画布上，我们可以在打开和关闭高光时避免这种成本。
全面测试跟踪记录解析
从头开始构建新功能的一个好处是，您可以反思之前做出的技术选择并做出改进。我们想要改进的一个方面是，明确地将代码拆分为两个几乎完全不同的部分：
解析跟踪文件并提取所需的数据。渲染一组轨道。
通过将解析（第 1 部分）与界面工作（第 2 部分）分开，我们能够构建一个可靠的解析系统；每个轨迹都通过一系列负责不同关注点的处理程序运行：LayoutShiftHandler 会计算布局偏移所需的全部信息，而 NetworkRequestsHandler 专门处理拉取网络请求。设置这个明确的解析步骤，让不同的处理程序负责跟踪的不同部分，这样做也会很有帮助：跟踪解析可能会变得非常复杂，并且有助于一次专注于一个问题。
此外，我们还能在开发者工具中采集记录，保存并在测试套件中加载这些记录，从而全面测试轨迹解析。这非常有用，因为我们可以使用真实跟踪记录进行测试，而不会积累大量可能过时的虚假跟踪记录数据。
画布界面的屏幕截图测试
继续围绕测试主题，我们通常对前端组件进行测试，方法是将它们呈现到浏览器中并确保其行为符合预期；我们可以分派点击事件来触发更新，并断言组件生成的 DOM 正确无误。这种方法对我们来说效果不错，但在考虑渲染到画布时就会失败；无法检查画布并确定其中绘制的内容！因此，我们通常采用渲染和查询的方法并不合适。
为了扩大测试范围，我们安排了屏幕截图测试。每次测试都会触发画布、渲染要测试的轨道，然后截取画布元素的屏幕截图。然后，此屏幕截图会存储在我们的代码库中，将来的测试运行会将存储的屏幕截图与其生成的屏幕截图进行比较。如果屏幕截图不同，测试将失败。我们还提供了一个标志来运行测试，并在我们有意更改呈现并需要更新测试时强制更新屏幕截图。
屏幕截图测试并不完美，而且有点生硬；您只能测试整个组件能否按预期呈现，而不是测试更具体的断言。最初，我们经常因为过度使用它们来确保每个组件（HTML 或画布）都能正确呈现。这极大地减慢了我们的测试套件的速度，并导致出现一些问题，即微小且几乎不相关的界面调整（例如细微的颜色变化，或在项目之间添加一些外边距），导致多张屏幕截图失败并需要更新。现在，我们已缩减屏幕截图的使用，将屏幕截图仅用于基于画布的组件，到目前为止，这种平衡效果不错。
总结
构建新的效果数据分析面板对团队来说是一次非常愉快的培训体验。我们学习了很多关于跟踪文件、画布使用方法等方面的知识。希望您会喜欢这个新面板，并热切期待听到您的反馈。
要详细了解“效果数据分析”面板，请参阅效果数据分析：获取有关网站效果的富有实用价值的分析洞见。
下载预览渠道
您可以考虑将 Chrome Canary 版、Dev 版或 Beta 版用作默认开发浏览器。通过这些预览渠道，您可以使用最新的开发者工具功能，测试先进的网络平台 API，并在用户采取行动之前发现网站上的问题！
与 Chrome 开发者工具团队联系
使用以下选项讨论博文中的新功能和变化，或讨论与开发者工具有关的任何其他内容。
- 通过 crbug.com 提交建议或反馈。
- 使用开发者工具中的更多选项
> Help > Report a DevTools issues来报告开发者工具问题。 - 发推文：@ChromeDevTools。
- 请在 YouTube 视频或“开发者工具提示”YouTube 视频中留言说明“开发者工具的新变化”。