?雖然Web性能的實踐已經(jīng)存在了一段時間，并且多年來研究和調(diào)試JavaScript (JS)錯誤的能力有所提高，但我們從未真正關注過錯誤對性能的影響。

JavaScript錯誤是Akamai的真實用戶監(jiān)控 (RUM) 工具 (mPulse ) 收集的更復雜的指標之一，作為一名數(shù)據(jù)科學家，我已經(jīng)研究這些數(shù)據(jù)幾年了。在這篇文章中，我將談談我的一些發(fā)現(xiàn)。

挑戰(zhàn)

那么，我們在分析JS錯誤時從哪里開始呢？任何JS錯誤跟蹤服務的用戶都會立即觀察到唯一錯誤的數(shù)量增長得非常快。這使得在數(shù)據(jù)中找到模式并最終診斷站點上的問題區(qū)域變得極其困難。幸運的是，許多獨特的錯誤并不是真的那么獨特。事實上，許多錯誤彼此非常相似，只是在語法上略有不同。這些變化可能由于多種原因而發(fā)生，例如（但不限于）：

（1）瀏覽器如何呈現(xiàn)錯誤的差異：

參數(shù)列表后缺少 )

SyntaxError: missing ) 在參數(shù)列表之后

（2）相同的錯誤對象引用出現(xiàn)在不同的數(shù)組索引處：

錯誤：無法解析具有未知索引“5”的 iframe

錯誤：無法解析具有未知索引“7”的 iframe

錯誤：無法解析具有未知索引“21”的 iframe

（3）不同變量名稱的相同邏輯錯誤：

ReferenceError: '$' 未定義

ReferenceError: 't' 未定義

ReferenceError: 'f' 未定義

根據(jù)客戶的不同，此類類似錯誤消息的出現(xiàn)可能會在JS錯誤數(shù)據(jù)中出現(xiàn)數(shù)十到數(shù)百次。我們通過重復數(shù)據(jù)刪除并對一組更易于管理的錯誤進行分析，從而利用這些共性來發(fā)揮我們的優(yōu)勢。

例如，上面的第二組錯誤將成為一組錯誤，其形式為“錯誤：無法解析具有未知索引 <*> 的iframe”，其中 <*> 是索引值的占位符。

為什么對錯誤計數(shù)發(fā)出警報還不夠

了解JS錯誤何時發(fā)生以及跨越哪些頁面是了解錯誤對網(wǎng)站的影響的重要第一步。然而，簡單地監(jiān)控發(fā)生的錯誤數(shù)量并不能為監(jiān)控整個網(wǎng)絡流量提供任何額外的好處。

這里的原因是許多頁面包含JS錯誤，因此，錯誤的數(shù)量幾乎與Web流量的規(guī)模完全相關。我的mPulse 產(chǎn)品團隊引入了一個名為“每頁錯誤數(shù)”的指標來解決這個問題。

“每頁錯誤數(shù)”定義為JS錯誤數(shù)除以感興趣時間段的頁面瀏覽量。這使我們能夠意識到并及時了解錯誤數(shù)量相對于信標數(shù)量激增的時間。雖然這個指標非常有用，但不幸的是，由于JS錯誤的性質(zhì)，它并不完美。在某些情況下，錯誤很普遍，但卻是良性的。也就是說，錯誤發(fā)生率高并不一定等同于糟糕的用戶體驗或對網(wǎng)絡性能的影響。在不了解其他信息的情況下，我們無法確定這種廣泛存在的錯誤是否真的具有影響力或只是以高發(fā)生率發(fā)生。出于這個原因，我們必須深入研究Web性能指標以獲得更清晰的畫面。

表現(xiàn)

雖然較慢的頁面通常會導致糟糕的用戶體驗，但重要的是要密切關注似乎已經(jīng)顯著改善的指標——那些幾乎好得令人難以置信的指標。想象一個頁面被破壞到頁面加載過程完全中斷并且頁面加載速度非常快的情況。負責監(jiān)控網(wǎng)站健康狀況的人員可能會對與這些頁面相關的錯誤感興趣。

在我們的一項分析中，我們查看顯示錯誤的頁面與不存在該特定錯誤的類似頁面。然后，我們使用此分叉來檢查各種頁面加載過程的時間，以查看錯誤出現(xiàn)和不出現(xiàn)的時間是否存在差異。在這里，我們并排繪制了顯示兩種情況的頁面加載時間 (ms) 分布的箱線圖。

在圖1中，我們看到了一個示例，該示例展示了當網(wǎng)站上不存在錯誤（左）時的頁面加載時間分布與存在此錯誤時的類似頁面（右）相比，頁面加載時間分布顯著加快。

△圖1

在圖2中，我們看到了一個相反情況的示例——當出現(xiàn)錯誤時，頁面速度顯著變慢（在中位數(shù)處慢兩倍多）。事實證明，這種情況更為常見。

△圖 2

最后，在圖3中，我們遇到了一個潛在良性錯誤的情況，無論是否存在錯誤，頁面加載過程都沒有太大差異。

△圖 3

JavaScript 錯誤的間接副作用

在分析RUM數(shù)據(jù)中的JS錯誤時，我們開始考慮最終用戶在面對致命或破壞其流程的錯誤時可能會表現(xiàn)出什么樣的行為。我們在數(shù)據(jù)中看到，某些錯誤的存在會導致用戶沮喪的行為，這對服務于網(wǎng)站的業(yè)務有底線影響。兩個最突出的情況是重新加載和放棄（頁面退出）。

重新加載

在JS錯誤的上下文中，我們認為會話中下一頁的重新加載（特別是重新加載的高發(fā)生率）表明錯誤本身與導致用戶沮喪的頁面相關聯(lián)。重新加載可能由多種原因引起，包括：

（1）由于頁面加載時間過長而導致的不耐煩

（2）頁面上的某些內(nèi)容未正確呈現(xiàn)

（3）該頁面顯示非200級響應代碼

要點是，高重新加載率會提醒我們發(fā)生錯誤的頁面上的特定問題。

出口

知道用戶退出頁面的原因并不總是顯而易見的，尤其是與JS錯誤有關的情況。通常，用戶退出或結束會話并不值得關注。例如，考慮一個用戶剛剛完成了他們在網(wǎng)站上的預期操作（進行了購買、找到并閱讀了特定文章等）。在這種情況下，退出站點是用戶會話的自然結束。但是，由于網(wǎng)頁速度慢或損壞，用戶可能會比預期更快地退出站點。在這里，我們對這些頁面上出現(xiàn)的JS錯誤特別感興趣。

在此分析中，我們檢查了在訪問出現(xiàn)特定錯誤的頁面后會話（訪問的頁面數(shù)）持續(xù)了多長時間。例如，考慮以下5個框給出的包含5個頁面的會話。

△圖 4

假設我們在第3頁上看到一個錯誤，比如錯誤XYZ。假設會話長度為5頁，則在看到錯誤XYZ后會話中剩余的頁數(shù)為2頁。

△圖 5

但是，如果我們在會話的第5頁上看到錯誤XYZ表面，則會話中剩余頁面的數(shù)量將為0。換句話說，會話在訪問具有此錯誤XYZ的頁面后結束。

△圖 6

在此分析中，我們在看到每種類型的錯誤后匯總了會話中剩余頁面的值。然后很明顯，在用戶會話的最后一頁上完全（或幾乎完全）發(fā)現(xiàn)了客戶網(wǎng)站上的某些錯誤。這些將是我們將進一步挖掘的錯誤，以找出可能導致用戶會話結束的原因。

圖7使用一系列并排的箱線圖顯示了這種分析。每個錯誤都有自己的箱線圖，沿x軸用名稱表示。y軸顯示看到錯誤后會話中的剩余頁面。剩余頁面的廣泛分布表明在錯誤浮出水面后有許多可能的用戶旅程。我們可能會得出結論，雖然該錯誤可能對某些用戶造成了破壞，但它并沒有阻止大多數(shù)用戶繼續(xù)他們的會話。這些案例位于圖7的右側。

△圖 6

更有趣的是，圖表左側更緊密的分布顯示了似乎影響用戶繼續(xù)會話能力的錯誤。具體來說，最左邊的四個錯誤就是我們所說的會話殺手。每次用戶訪問存在這些錯誤之一的頁面時，在每種情況下，會話都會停止繼續(xù)。

通常，此類破壞性錯誤出現(xiàn)在一組特定的頁面尺寸值上。例如，特定版本的瀏覽器、特定頁面組、特定操作系統(tǒng)、特定地理位置，或者有時是所有這些的組合。準確了解錯誤導致性能下降的位置為開發(fā)人員維護站點的健康提供了明確的行動計劃。

結論

隨著網(wǎng)絡性能工具變得越來越復雜，我們收集的數(shù)據(jù)以及我們打算用這些數(shù)據(jù)回答的問題也越來越復雜。雖然我們有關于JS錯誤的數(shù)據(jù)，但分析它并不總是一個簡單的問題。我們的目標是消除這些數(shù)據(jù)中的噪音，并查明對性能有實際影響并因此導致最終用戶體驗下降的JS錯誤。

對我和我的團隊來說，圍繞JS錯誤的分析仍然是一個活躍的研究領域。我歡迎對上述信息提出任何問題、意見、疑慮和一般反饋。

[1] JavaScript錯誤是通過啟用錯誤插件的開源boomerang.js 包收集的。

[2] 我們運行基于JS錯誤之間的字符串編輯距離的聚類算法。這種分析使我們能夠根據(jù)錯誤返回的字符串將我們認為具有相同來源的錯誤分組在一起。在上面的示例中，我們將提供一組錯誤的聚合Web 性能指標值，而不是單獨的單個錯誤。這個集群和聚合步驟使得從數(shù)據(jù)中收集見解和確定網(wǎng)站上JS錯誤的性能影響變得更加容易。

[3] 為了維護客戶數(shù)據(jù)的機密性，我有意省略了下圖中所討論的具體錯誤。

[4] 通過performance.navigation.type返回值1給出重新加載。在計算重新加載率時，我們感興趣的是在看到當前頁面上的錯誤后，在會話中的下一頁上發(fā)生這種情況的次數(shù)。

[5] 請注意，具體的錯誤名稱替換為隨機生成的字符串。

*原文鏈接：https://calendar.perfplanet.com/2021/performance-implications-of-javascript-errors/?