虽然web性能的实践已经存在了一段时间，研究和调试JavaScript(JS)错误的能力这些年来也有所提高，但我们从未真正关注过它的影响性能上的错误。JavaScript错误是Akamai的真实用户监控(RUM)工具(mPulse)收集的更复杂的指标之一，作为一名数据科学家，我多年来一直在研究这些数据。在这篇文章中，我将谈谈我的一些发现。挑战那么，我们在分析JS错误时从哪里开始呢？任何JS错误跟踪服务的用户都会立即观察到独特错误的数量增长得非常快。这使得在数据中找到模式并最终诊断网站上的问题区域变得极其困难。幸运的是，许多独特的错误并不是真的那么独特。事实上，许多错误彼此非常相似，只是在语法上略有不同。发生这些变化的原因有很多，例如（但不限于）：(1)浏览器呈现错误的方式不同：(SyntaxError:missing)在参数列表之后(2)相同的错误对象引用发生在不同的数组indices:Error:Unabletoparseiframewithunknownindex"5"Error:Unabletoparseiframewithunknownindex"7"Error:Unabletoparseiframewithunknownindex"21"(3)ofdifferentvariablenames同样的逻辑错误：ReferenceError:'$'isnotdefinedReferenceError:'t'isnotdefinedReferenceError:'f'isnotdefined根据客户的不同，这种类似的错误信息的出现可能在JS错误数据中出现几十到几百次Second-速度。我们通过删除重复数据和分析一组更易于管理的错误来利用这些共性。例如，上面的第二组错误将变成一组错误，形式为“错误：无法解析具有未知索引<*>的iframe”，其中<*>是索引值的占位符。为什么只对错误计数发出警报是不够的了解JS错误何时发生以及它们跨越哪些页面是了解错误对您网站的影响的重要的第一步。然而，仅仅监控发生的错误数量并不能为监控整体网络流量提供任何额外的好处。这里的原因是很多页面都包含JS错误，因此，错误的数量几乎与网络流量的规模完全相关。我的mPulse产品团队引入了一个名为ErrorsPerPage的指标来解决这个问题。“每页错误数”定义为JS错误数除以相关时间段内的页面浏览量。这使我们能够意识到并及时了解错误数量相对于信标数量何时出现峰值。虽然此指标非常有用，但不幸的是，由于JS错误的性质，它并不完美。在某些情况下，错误很普遍，但却是良性的。也就是说，高错误率并不一定等同于糟糕的用户体验或对网络性能的影响。在没有其他信息的情况下，我们无法确定这个广泛存在的错误是否真的具有影响力或只是发生率很高。出于这个原因，我们不得不深入研究网络性能指标以获得更清晰的画面。性能虽然较慢的页面通常会导致糟糕的用户体验，但重要的是要密切关注似乎已显着改善的指标——这些指标好得令人难以置信。想象这样一种情况，页面被破坏到页面加载过程完全中断并且页面加载速度非常快的程度。与这些页面相关的错误可能会引起负责监控网站健康状况的人员的兴趣。在我们的一项分析中，我们查看了显示错误的页面与没有该特定错误的类似页面。然后我们使用这个分支来检查各种页面加载过程的时间，看看错误发生和不发生的时间是否存在差异。在这里，我们并排绘制了一个箱线图，显示了两种情况下页面加载时间(ms)的分布。在图1中，我们看到了一个示例，该示例说明当网站上不存在错误（左）时页面加载时间的分布如何比存在错误时（右）加速的类似页面明显更多。△图1在图2中，我们看到了一个相反情况的例子——当错误发生时，页面速度明显变慢（在中值处慢了两倍多）。事实证明，这种情况更为普遍。△图2最后，在图3中，我们遇到了一个潜在良性错误的情况，无论有没有错误，页面加载过程都没有太大区别。△图3JavaScript错误的间接副作用在分析RUM数据中的JS错误时，我们开始考虑最终用户在面临致命错误或中断其流程的错误时可能会有怎样的行为。我们在数据中看到，某些错误的存在会导致令人沮丧的用户行为，这对为网站提供服务的业务具有底线影响。两个最突出的案例是重新加载和放弃（页面退出）。重新加载在JS错误的上下文中，我们认为会话中下一页的重新加载（特别是重新加载的高频率）表明错误本身与导致用户沮丧的页面相关联。重新加载可能由多种原因引起，包括：（1）由于页面加载时间太长而导致不耐烦（2）页面上的某些内容无法正确呈现（3）页面显示非200级响应代码重点是，高重新加载率提醒我们在发生错误的页面上存在特定问题。退出了解用户退出页面的原因并不总是显而易见的，尤其是当它与JS错误有关时。通常，用户注销或结束会话时无需担心。例如，考虑刚刚在网站上完成预期操作（进行购买、找到并阅读特定文章等）的用户。在这种情况下，退出站点是用户会话的自然结束。但是，由于网页速度慢或损坏，用户可能会比预期更早退出网站。在这里，我们对这些页面上发生的JS错误特别感兴趣。在此分析中，我们检查了在访问具有特定错误的页面后会话持续了多长时间（访问的页面数）。例如，考虑给定以下5个框的5页会话。△图4假设我们在第3页看到一个错误，说错误XYZ。假设会话长度为5页，则在看到错误XYZ后会话中剩余的页面数为2页。△图5但是，如果我们在session的第5页看到了错误的XYZ面，那么session的剩余页数就会为0。也就是说，在访问了这个错误XYZ的页面后，session就结束了。△图6在此分析中，我们在看到每种类型的错误后汇总了会话中剩余页面的值。然后很明显，在用户会话的最后一页上完全（或几乎完全）发现了客户网站上的某些错误。这些将是我们将进一步深入研究的错误，以找出可能导致用户会话结束的原因。图7使用一系列并排的箱线图显示了此分析。每个错误都有自己的箱线图，沿x轴用名称表示。y轴显示出现错误后会话中的剩余页面。剩余页面的广泛分布表明，在错误浮出水面后，可能会有许多用户旅程。我们可能会得出结论，虽然该错误可能对某些用户造成了干扰，但它并没有阻止大多数用户继续他们的会话。这些情况位于图7的右侧。△图6更有趣的是，图表左侧的分布更紧密，显示的错误似乎会影响用户继续会话的能力。具体来说，最左边的四个错误就是我们所说的会话杀手。每次用户访问带有这些错误之一的页面时，在每种情况下会话都会停止继续。通常，此类破坏性错误出现在一组特定的页面大小值上。例如，特定版本的浏览器、特定的页面组、特定的操作系统、特定的地理位置，或者有时是所有这些的组合。准确了解错误导致性能下降的位置可为开发人员制定明确的行动计划，以维护站点的健康。结论随着网络性能工具变得越来越复杂，我们收集的数据和我们打算用它来回答的问题也变得越来越复杂。虽然我们有关于JS错误的数据，但分析它并不总是一件简单的事情。我们的目标是消除这些数据中的噪音并查明对性能有实际影响并因此降低最终用户体验的JS错误。围绕JS错误的分析对我和我的团队来说仍然是一个活跃的研究领域。我欢迎对上述信息提出任何问题、意见、疑虑和一般反馈。[1]JavaScript错误是通过启用错误插件的开源boomerang.js包收集的。[2]我们基于JS错误之间的字符串编辑距离运行聚类算法。此分析允许我们根据错误返回的字符串将我们认为具有相同来源的错误分组在一起。在上面的示例中，我们将为一组错误提供聚合的Web性能指标值，而不是单个错误。此聚类和聚合步骤可以更轻松地从数据中收集见解并确定JS错误对您网站的性能影响。[3]为了维护客户数据的机密性，我特意省略了下图中讨论的具体错误。[4]通过从performance.navigation.type返回值1来重新加载。在计算重新加载率时，我们感兴趣的是当前页面上的错误在会话的下一页上出现了多少次。[5]请注意，特定的错误名称已替换为随机生成的字符串。*原文链接：https://calendar.perfplanet.com/2021/performance-implications-of-javascript-errors/
