前端调试很糟糕而且应该感觉很糟糕

来源

如果您陷入了像我所描述的痛苦的前端调试过程，那么了解可观察性并努力在您的 Web 服务中实现它可以减轻痛苦，并让您更轻松地充满信心地交付东西。 让我们看看这在实践中是如何运作的。

前端领域的可观察性 1.0

考虑一个许多从事 Web 服务的开发人员可能熟悉的任务：使用 Google 的 Core Web Vitals 指标等度量来调试较差的页面性能分数。 这些指标衡量您网站的速度和可用性的表现：

• 最长内容绘制 (LCP) 跟踪内容在页面上显示的速度
• 累积布局偏移 (CLS) 衡量内容是否发生偏移或稳定
• 与 Next Paint 的交互 (INP) 衡量代码响应用户输入的速度

Google 会跟踪您的表现 这些指标 并将其用作搜索排名的信号。 如果您关心搜索排名，您可能也会关心 CWV。 谷歌的指标也与用户体验有关，所以即使你不太关心搜索排名，你 大概 关心用户在页面上的体验。 因此，这些指标可用于跟踪用户体验的某些方面。

如何改善较差的 CWV 分数？

对于当今的大多数开发人员来说，这是一个使用监控工具（可能是真实用户监控产品）来了解哪个指标较差的有趣游戏。 如果您的网站有数千个页面，则全局 CWV 指标可能根本没有帮助； 它不会为您提供任何有关查找位置的指导。

大多数监控工具允许您按几个维度进行切片，因此您可以缩小范围到特定的设备类型或页面路由，以帮助您的调查提供信息。 一旦您将指标划分为可能出现问题的最小区域，您就需要使用 不同的 用于调试的工具集。

您可以安装浏览器插件并浏览实时网站上的特定页面，看看是否可以找出当前问题的罪魁祸首。 然而，在复杂的 Web 服务中，您的复制能力可能取决于重新创建必要的条件：

• 是否有不同的功能标志可能会影响页面的行为方式？
• 经过身份验证的用户是否会获得与匿名用户不同的体验？
• 是否存在生成低分条件的特定页面状态（购物车中的商品、特定类型的搜索、需要启用的关键权利）？

如果您的 CWV 监控工具不包含任何此类上下文，您将不会知道。 您必须进行大量实验来捕获每种可能的排列，才能看看您能找到什么。 我对此深为熟悉。 几年前，当 Google 推出 CWV 时，我在一家大型媒体公司工作。 我的职责是查明得分不佳的原因，并为公司的两个内容管理系统找到技术修复方案，以避免在 CWV 成为搜索结果中的一个因素时受到处罚。 我真的花了 周 建立假设，尝试验证它们，然后与多个团队合作来测试潜在的解决方案，包括关闭低流量网站的付费墙一段时间，只是为了看看这是否是导致分数不佳的一个因素。 该测试的结果完全不确定 – 更改付费专区的某些 CSS 值可能会完全解决 CLS 问题，但也有可能没有效果。

我刚才描述的——整个调试周期和我多年前的经历——就是我们 Honeycomb 称之为可观察性 1.0 的东西。

你有很多不同的事实来源，唯一将它们联系在一起的是你，工程师。

慈善专业

在可观察性 1.0 世界中，您可以 最终 获取解决诸如糟糕的 CWV 指标之类的问题所需的所有数据和信息，但这将是一个昂贵的过程 – 无论是在工具成本上还是在可能需要的小时数上。

使用 OpenTelemetry 提高可观测性

在我离开媒体公司后的一段时间，我加入了 Honeycomb，并在实践中开始学习 OpenTelemetry 和可观察性。 我了解到到目前为止我所描述的一切并不是唯一可用的选择。 前端开发人员的生活可能会更好——这些调试周期可能会更快、更容易。 理论上不是，但是 实际上。

让我们继续使用 Core Web Vitals 示例。 大多数（如果不是全部）RUM 工具都可以开箱即用地跟踪 Core Web Vitals。 他们通常使用 Google 的小型工具来完成此操作 web-vitals NPM包，它捕获每个页面加载时的 Web Vitals 事件。 这些 RUM 工具捕获指标并将其汇总为聚合，以便您可以了解站点的性能。 那 web-vitals 包裹 还 生成大量归因数据：

• 到底是什么导致了指标不佳？
• 哪个元素发生变化而创建了 CLS？
• 下一次绘制时哪种交互速度较慢？
• 哪个元素算作 LCP 的“最大”元素？

如果您捕获了所有归因数据，您的指标将具有 很多 更多背景信息。

在 Honeycomb，我们非常喜欢 OpenTelemetry，这是一个用于供应商中立的仪器和遥测的开源项目。 OpenTelemetry 允许您在应用程序中检测您关心的内容，并将数据发送给任何支持它的供应商，例如 Honeycomb。 由于 OpenTelemetry 不是像 RUM 代理那样的专有仪器库，因此它允许您非常灵活地捕获了解系统所需的数据，例如 web-vitals 归因数据。

我在 Honeycomb 的团队最近发布了一个 网络仪表包 建立在 OpenTelemetry 之上。 该软件包跟踪所有开箱即用的 Core Web Vitals 指标， 以及归因数据。 网络工具还捕获了更多信息； 标准信息，例如设备类型、页面数据、浏览器信息等。

然而，捕获数据并不是那么令人兴奋。 当您可以利用它来解决您的问题时，就会感到兴奋。

Observability 2.0：改进前端调试

当您有更丰富的数据集可供使用时，Core Web Vitals 调试变得更加容易。 我们的仪器包捕获 CWV 数据作为 OpenTelemetry 轨迹。 跟踪是一种结构化日志，由一个或多个跨度组成，每个跨度可以有许多（最多 2,000 个！）属性。 属性是键/值对。 在 Honeycomb 中，您可以查询任何跨度或跨度属性，从而允许您以任何方式对数据进行切片和切块。

在 Core Web Vitals 示例中，假设您发现某些用户的页面加载的 CLS 分数非常低。 借助 Honeycomb 的 Web 工具，捕获的每个 CLS 指标都附带 许多 为数据提供上下文的跨度属性。 您可以首先查询名为的所有事件的平均值 cls。 这不会给你太多信号。 因此，开始对其进行切片，也许可以通过 URL 将值分解。 现在您可以查看某些页面是否异常，如果是，则向下过滤 只是那些页面。 按浏览器或屏幕尺寸细分数据将帮助您了解分数分布中是否出现更多模式。

第一步调查试图定位 在哪里 问题是——过滤到站点中需要解决的特定位置。 不过，还有更多：Honeycomb 仍然有一个 山 您可以显示的数据。

一旦您找到了感兴趣的领域，您就可以探索 CWV 归因数据！ 每个 CLS 指标事件都有该归因数据，因此，如果您已将问题范围缩小到特定屏幕尺寸上的特定页面，请分解归因数据以查看标识的元素选择器。 可能不会有很多； 通常，在任何给定页面上，只有少数元素会导致最大的问题。 您可以抓取其中一个元素选择器，访问您网站上的页面，将浏览器设置为正确的宽度，然后运行 querySelectorAll() 调用选择器来查找元素。

在短短几分钟内，您就从意识到问题的存在变成了可能的罪魁祸首。 这就是可观察性2.0的力量。

然而，乐趣还不止于此。 因为您正在捕获指标和上下文，所以您可以发布修复程序，然后检查您的工作。 一旦更新的代码投入生产，您就可以提取相同的查询来查看是否有有意义的改进。 Observability 2.0 允许您调试和识别罪魁祸首，然后确认解决方案适用于相同的工作流程，确保您有信心解决已解决的问题并继续处理下一个优先事项。

回顾：前端调试并不一定很痛苦

这篇博文涵盖了很多材料，因此我想确保指出其中的重点。 如今的前端调试很糟糕，因为它陷入了可观察性 1.0 的世界。 有很多工具可以收集大量有关用户在您的网络服务上体验的指标和数据。 这些数据通常会提醒您存在问题，但要调试原因，您需要结合大量的调查工作和猜测。

通过利用 OpenTelemetry 等开源工具，可以极大地改进前端调试 开始检测您的网络服务 与您关心的数据。 实践可观察性意味着广泛地进行检测； 不仅仅是捕获感兴趣的指标，而是与该指标相关的任何和所有上下文，以帮助您理解它。 如果您这样做，那么您就能够提出问题，快速迭代地探索数据，找到相关性，并更快地找到根本原因。

Honeycomb 的网络工具为您提供了一个很好的起点，捕获一组丰富的初始数据。 然而，可观察性的强大之处在于您不仅限于自动收集的内容。 您可以添加您关心的上下文和信息，并立即开始享受可观察性 2.0 为您提供的丰富的调查能力——大量上下文数据，全部集中在一处，让您感到好奇。 今天免费试用。