如何使用新的Relic浏览器改善Web应用程序的用户体验

没有人喜欢等待，根据研究（不幸的是，对于Web开发人员而言），我们只会变得更加急躁。

内容交付网络公司Akamai的最新消费者报告中共享的数字令人信服：49％的电子商务客户期望页面在两秒钟或更短的时间内加载，其中很大一部分需要即时页面加载（一秒钟或更短）。 报告还说，消费者对慢速网站的耐心仍在下降：“目前，只有51％的消费者“耐心等待”网站加载，而五年前只有63％的消费者“耐心等待”。 ”

同样，为了使事情更加复杂，在当今的许多网站和应用程序上，访问开始时原本只是一页的加载已发展为用户，Web浏览器和应用程序之间发生的几种交互。

在一个充满选择的世界中，沮丧的访客不会停留太长时间，这可能是由于初始加载时间缓慢或AJAX加载图像永不停止旋转所致。

那么，我们该怎么做才能防止访客感到沮丧？

在本教程中

如果您是Web开发人员或运行基于Web的服务，该服务可以收集任意数量的访问者，但是不确定您的产品是否有某些令人沮丧的访问者，那么本教程适合您。

在本教程中，我们将使用New Relic Browser来找到访问者在使用您的网站或应用程序时遇到的挫败点。 这包括优化页面加载及其不同部分，以及在用户的Web浏览器中弹出JavaScript错误后立即查找并修复这些错误。

如果您还不是New Relic用户，则只需阅读教程并应用建议的修补程序，就可以对优化Web应用程序有所了解。 但是，为了充分利用接下来的内容，建议您尝试使用Browser并注册14天免费试用版 。 我敢打赌，您会发现在那个时期已经有很多摆脱沮丧的机会了...

新的Relic浏览器入门

New Relic Browser是一种新型的监视工具：与其监视服务器上发生的加载时间和事件，不如将焦点转移到最终用户体验上。 从用户键入URL或单击链接一直到离开页面的那一刻，这使开发人员可以详细了解真实用户如何加载页面并与之交互。

Jeff Reifman在较早的教程“ 使用New Relic Browser进行前端监视”中总体上介绍了New Relic Browser ，所以这次我将不详细介绍如何安装该产品。 相反，如果您不熟悉Browser，建议您先看一下Jeff的教程，然后返回本教程以获取有关如何使用该工具进行实际优化的提示和想法。

在没有完整的新文物堆栈的情况下安装新的文物浏览器

但是，有一个例外：自Jeff的教程于2014年10月发布以来，New Relic添加了一个选项，可以在网站上使用浏览器，而无需在服务器上安装完整的应用程序监视堆栈。

对于大多数用户来说，建议的做法是使用Jeff教程中介绍的将浏览器作为完整APM软件包的一部分安装的默认方法，因为它将为您提供有关在服务器上花费的时间的最准确信息。 但是，如果您无法在服务器上安装软件（例如，在共享的Web主机上，则可能是这种情况），则替代方法对您很有用。

这是在不安装其余New Relic服务器监视工具的情况下安装Browser的方法。

首先，一旦注册，请单击页面右上角的“ 添加更多 ”以添加您的应用程序。

在下一个屏幕上，选择“ 复制/粘贴JavaScript代码”作为部署方法。

然后，为您的应用程序命名，然后点击Generate Snippet 。

该代码将附加在页面上按钮的正下方：

复制生成的代码，并将其放在您网页的head ，并尽可能靠近顶部，但要放在任何meta标签之后。 就是这样。

给New Relic一些时间来收集有关访问者的数据，然后返回浏览器仪表板以查看发生了什么。 刚开始时，事情看起来有些空虚，但是没有后顾之忧：随着人们访问您的网站，您很快就会有大量数据需要分析！

现在，我知道您渴望解决实际问题并改善用户的生活，所以让我们直接开始工作吧！

核心功能：会话跟踪

使用工具的方式总是不止一种，我们都有自己的喜好。

就是说，刚开始时，最好有一些经过测试的想法来作为实验的基础。 这就是为什么，在研究本教程时，我花了一些时间看着一位经验丰富的New Relic工程师向我展示了他如何使用浏览器在New Relic的代码库中查找问题和优化点。

该演示的最大收获是，New Relic Browser的核心杀手级功能是Session Traces 。 虽然浏览器还具有其他有用的功能，但最好将它们理解为旨在帮助您最大程度地利用会话跟踪的工具。

什么是会话跟踪？

会话跟踪看起来很像您在喜欢的Web浏览器的开发人员工具中找到的时间线，除了在这种情况下，该跟踪没有显示您的体验，而是显示了一位访问者在计算机上发生的事情。 因此，它不是访问者总数的摘要或平均值，而是一个捕获的会话，它在不牺牲访问者隐私的情况下，尽可能详细地向您显示页面加载的整个生命周期。

以下示例显示了会话跟踪的开始，该会话跟踪显示了一个Android Chrome用户访问我的杂志网站上的杂志档案：

要从头到尾遍历会话跟踪，请将指针放在跟踪元素的顶部，然后使用鼠标或触摸板向下滚动。 跟踪跟踪加载的事件和资源，并逐一向您显示它们。 您也可以使用左上角的+和-按钮放大和缩小轨迹，或单击顶部鸟瞰视图中的任意位置以跳到轨迹中的更远一点。

通过将指针放在资源或事件的顶部，您将看到有关该元素的更多信息。 例如，下面的屏幕截图中的浅绿色条显示了加载的图像很大或由于其他原因而缓慢...

要在时间轴上查看整个资源，请单击它。 这样可以将视图缩放到足够远，以使条形图适合屏幕，您一眼就能看到其与其余迹线的比较。

如何选择一个有趣的会话跟踪进行分析

如上所述，会话跟踪是一个用户与应用程序页面之一进行交互的记录。 因此，尽管许多会话跟踪可能很好地代表了访问者，但总是存在异常现象：缓慢的跟踪可能很慢，这仅仅是因为访问者正在使用旧计算机或互联网连接不良。

这意味着您必须根据自己的判断来决定是否应关注特定的跟踪。 在开始优化页面加载时，我们将详细选择一个好的跟踪，但是总的来说-是为了优化页面加载或修复JavaScript错误-尝试查找一个代表访问者的跟踪是一个好主意接近您的普通用户，并会影响一个受欢迎的页面。

这样，您的修补程序将对大多数用户产生重大影响。

让我们从加速用户体验到的网站加载开始。

使用新的遗物浏览器优化您的网站

优化您的网站是您可以采取的最重要的措施之一，以确保您的访问者不会感到沮丧，并留给竞争对手或使您分心。 但是，由于您尝试了许多不同的优化方法，因此通常很难决定从哪里开始：如果您只是一个接一个地实施修订，则最终可能会优化您的站点，而一个大问题仍未解决。

这是浏览器为我们提供帮助的地方。

您无需花时间进行直觉的随机修复，而是选择一些良好的，有代表性的会话跟踪，并使用它们来发现瓶颈，这些瓶颈确实在减慢用户所经历的加载时间，并专注于修复它们。

第1步：使用网页浏览量获取整体图片

在深入探讨会话跟踪之前，有助于全面了解最优化需求在应用程序或网站上的位置。

因此，让我们从“ 页面浏览量”页面开始。

首先，根据您的网站收到的流量，使用页面顶部的“ 时间选择器”选项选择一个时间范围，该时间范围将为您提供足够的数据，以便您根据以下决定做出决定：

• 对于高流量的Web应用程序，默认30分钟将很好地工作，并为您提供最新信息。 当您检查较早的修复程序是否对加载时间产生了预期的影响时，这也很有用。
• 对于访问者较少的较小站点，您可能需要更长的时间来收集足够大的样本量以对访问者做出假设。 例如，在下面的屏幕截图中，我使用了7天的时间范围。

除了查看最近的数据“ Ending now ”之外，您还可以使用“ 自定义日期”选项卡浏览历史数据，并查看在任何给定时间使用浏览器监视的应用程序的行为。

选择一个时间范围后，请看一下右侧的第一个图形， 浏览器页面加载时间 。

此图显示了网站加载时间的明细，并以不同的颜色突出显示了页面加载中的每个阶段。 从某种意义上讲，这就像会话跟踪的汇总版本一样，只是没有所有细节。

让我们看一下不同的阶段以及在这些阶段中会发生什么。 请注意，您可以单击图表下方的标签以显示或隐藏图层，并仔细查看其余图层。

• Web应用程序 ：从底部开始，紫色部分显示在应用程序服务器上执行请求所花费的时间。 我们优化网站的目标是能够尽快向用户展示某些内容，因此这一步骤至关重要。 如果Web应用程序占用了大部分请求，请跳至服务器端并修复初始加载时的问题，然后再继续进行客户端优化。 但是，在许多情况下，与其他三个部分相比，您已经发现该部分已经相当快，因此从其中之一开始，您通常会获得更好的投资回报。
• 网络：第二层从下至上以棕色显示，它显示了在初始服务器请求上花费的时间，包括将请求发送到服务器并检索响应。 它不包含加载静态资源的网络请求。 在此阶段，您的站点仍然显示空白页面，因此，如果网络时间很慢，则应优化服务器，例如，清理HTML代码或将其最小化以确保尽快加载。
  
• DOM处理和页面渲染 ：两个最上面的阶段，分别以浅黄色和蓝色显示，这是我们将使用浏览器获得最佳可见性的两个阶段。 这很好，因为它们通常也是最需要优化的，正如您从上面的屏幕截图中可以看到的。 DOM处理显示访问者的浏览器解析页面HTML所花费的时间，而页面渲染显示从浏览器解析HTML到页面完全加载并可供访问者使用的时间。

最后，在上面的屏幕截图中，您会注意到一些垂直的红线。 这些是New Relic监视工具启动警报的时间段 。 在这个示例中，取材自我（仍未完全优化）的杂志站点，由于服务器上的错误而生成警报一次，而由于服务器端的Apdex索引在一周内几次变得过低而生成了三次警报。

在分析页面加载时间表之后，您将更好地了解用户大部分时间都花在了哪里，并且可以相应地进行更深入的研究。

第2步：找到要优化的页面

现在，我们已经有了页面加载的整体视图，我们可以更深入地研究数据，从查看聚合图过渡到一次放大一个会话。 但是，正如我前面提到的，并不是每条痕迹都能很好地代表您的访问者，也不会在解决问题上投​​入大量时间。

在“ 页面浏览量”屏幕的左侧，您会找到一个对服务器的请求列表，按请求的URL分组，可以按不同的条件进行排序。 这是选择页面以进行工作时有用的工具。

不同的排序选项可用于从数据中挑出不同的见解：

• 总加载时间的百分比 ：这是默认视图，它显示了您所有网站上的总加载时间所花费的时间。 作为其他两个选项的一个因素，此视图将每个页面的受欢迎程度与其加载速度结合在一起，使您对修复将在何处产生最大影响有了一个很好的整体认识：一个很少显示的速度非常慢的页面将在列表中处于较低位置。 列表中排名靠前的页面之所以可以出现，是因为其与您网站的其余部分相比而言很受欢迎，或者它的速度非常慢。 如果不确定是这两种情况中的哪一种，则可以使用其他两种视图。
• 平均页面加载时间：此视图按页面的加载时间对页面进行排序，而不考虑受欢迎程度。 因此，如果不确定为什么页面在上面的列表中排名很高，请看一下该页面：如果页面在此列表和上面的列表中都显得很高，则该页面很可能既受欢迎又在需要优化-换句话说，是优化的理想选择。
• 吞吐量 ：此视图按访问者访问页面的频率对页面进行排序。 因此，类似于“平均页面加载时间”，您可以使用此选项来查看为什么页面在默认视图中排名高（或低），这仅仅是因为页面受欢迎吗？

使用此信息，在上面的屏幕截图中所示的情况下，我注意到该站点的主页位于列表的顶部。 仔细查看另外两个清单，可以发现/bread-making-books页面/bread-making-books该网站上最受欢迎的博客文章之一）实际上比主页要慢，但随着它收到的内容更多，主页的排名也更高。吞吐率（也不是那么快）。 因此，我将首先使用主页，但是肯定会在不久后返回以优化博客文章。

找到页面后，您认为最好将时间用于优化，是时候选择一条跟踪信息了。

当您单击列表中的页面之一时，将在右侧打开一个新视图，其中包含有关该页面历史的更多信息。

在此视图的顶部，您将从上一个“ 页面视图”屏幕中看到相同的数据，这次被过滤以仅显示该页面及其性能的数据。 在此图表下方，有一个显示该页面随时间推移的吞吐量。

要查找会话跟踪，请向下滚动至页面底部，您将在其中找到涉及此页面的近期会话跟踪的列表：

如您所记得，我们的目标是找到一个能够代表尽可能多的访客体验的网站。 但是，由于随机变量通常会影响任何特定的轨迹，因此在做出任何假设之前先查看多个轨迹还是一个好主意，或者使用一个轨迹收集假设，然后通过分析两个或多个其他轨迹来确认它们也是一个好主意。

也就是说，通过查看此列表中的数据，您可以对跟踪的有用性做出一些假设：

• 我们正在寻找可以优化的东西，因此更快的跟踪并不是那么有趣。
• 访问者的Web浏览器将向您介绍有关该用户的很多信息：运行旧浏览器的人很可能也在使用旧（慢）计算机。 您是否需要重点关注这个用户，取决于您要吸引的客户群。
• 此外，某些痕迹显然是异常值。 如果大多数迹线都在6秒或更短的范围内，那么花了24秒的迹线可能并不能代表所有的迹线。

在这种情况下，最长的页面加载时间是8.037秒，是在移动设备上的，因此这可能与所使用的网络有关。 这很可能值得一试，但是为了排除由于无法控制而导致的速度变慢，我决定从下两个开始：Mac Chrome跟踪花费了6.238秒，Android Chrome跟踪花费了5.174秒。

查看来自您自己服务器的数据，选择一些有希望的跟踪。 然后，拿一张纸（或在计算机上打开一个新的文本文档），并开始写下有关可能需要优化的内容的注释。

步骤3：分析会话跟踪

精心选择的会话跟踪将向您显示与“ 页面视图”概览图上看到的很多相同的数据，但更为详细-一次仅一次。

不同的站点要求进行不同的优化，因此，从此处继续的最佳方法是使用上面选择的会话跟踪来查找特定于您的站点和客户的问题。 例如，New Relic的服务器是高度数据驱动的，并且应用程序的界面依赖于AJAX调用，该调用用于检索要显示在其表和图中的数据。 另一方面，在像我这样的杂志和博客网站上，很多用户的时间都花在加载图像，视频和其他视觉内容上。

现在，让我们来追溯一下。

迹线分为四个部分，每个部分都带有彩色背景。 您会在页面右上角找到不同部分的标签和持续时间：

在此摘要中，您将找到四个与“ 页面视图”页面上显示的阶段相似但又不完全相同的步骤，以及两个额外的变量：

• 后端：这是页面加载中用于请求和等待网站HTML加载的部分。 如果将其与“页面视图”页面上显示的加载阶段进行比较，则该阶段会更长，因为它将Web应用程序阶段与网络阶段相结合。
• Dom处理：这是浏览器解析HTML并使用它来构造DOM所花费的时间。
• 页面加载：此阶段从构建DOM开始，一直持续到HTML引用的所有资源（图像，CSS文件，异步JavaScript文件）已加载。
• 等待Ajax：在一个高度依赖AJAX调用的网站上，这一点很重要，因为它显示了页面变得完全对访问者有用的时间点。 例如，在New Relic的仪表板上，这是所有图表对用户可见的时间。 在用于此示例跟踪的页面上，等待时间是针对从Tumblr API加载的流的，因此，以某种方式即使该页面尚未完全完成，该页面也可以在此里程碑之前使用。
• 本概述中的最后两个元素向我们介绍了用户的行为： 第一次交互显示用户何时“触摸”页面（通过滚动或单击某些内容）。 持续时间是跟踪的总长度，即用户在页面上停留的时间。
  

除此划分外，在会话跟踪的顶部，您还会注意到用颜色编码的行，它们向您展示了跟踪的鸟瞰图：

这些行在跟踪中显示事件，并按事件类型对其进行分类。 这很有用，因为所有请求都没有完全落入上述四个部分：您可能会在DOM处理阶段找到AJAX调用，并且在页面加载后仍在加载更多资产。

现在，我们一直在等待的时刻：让我们深入研究会话跟踪并探索我们可以在其中找到的与优化相关的不同问题以及建议的修复程序。

检查服务器请求上花费的时间

查看会话跟踪时，您会看到的第一件事是服务器响应请求所花的时间。 在浏览器中，大多数情况都是黑框，因为您只会看到Web浏览器看到的内容：标有小蓝点的事件表示与发出请求和接收响应有关的事件。

也就是说，本节确实帮助我们回答了三个重要问题：

1. 您的服务器代码是否需要优化？ 如果requestStart和responseStart之间的时间很长，则意味着您的服务器花费了大量时间来处理请求，并且可能需要进行优化。 在这种情况下，请跳至New Relic的APM和服务器端，并使用它们来查找所有时间。
2. 您HTML响应是否需要优化？ 通过查看responseStart和responseEnd之间的时间差，您将看到浏览器加载服务器响应（即HTML代码）花费了多长时间。 如果这段时间很长，则表明您应该对HTML响应本身做一些事情：考虑清理HTML代码并缩小代码以加快加载速度。
3. 专注于此会话跟踪是否有意义？ 如果标准的网络请求（例如域查找）花费的时间很长（ 根据Yahoo的说法 ，“ DNS通常需要20-120毫秒的DNS才能查找给定主机名的IP地址”），这是一个迹象用户可能正在通过慢速网络使用您的网站。 如果您的大多数用户或其中很大一部分用户都是这样，请使用此信息指导您并剪切所有精美的图形和大图像，并在连接速度较慢时也可以使站点快速运行。 否则，这意味着您可以继续进行下一个跟踪并重新开始。

检查花费在构建DOM树上的时间

访问者的Web浏览器开始解析服务器HTML响应后，会话跟踪将继续进行下一个阶段DOM Processing 。

在下面的屏幕快照中，我将其分为三个部分来帮助使其适合页面，您将看到三个事件，它们描述了浏览器浏览HTML内容并构建页面的DOM树时的进度。

• DOM处理从事件domLoading开始。 请注意，这已经在浏览器加载整个响应之前发生。
• 然后大约3秒钟，您会注意到domInteractive事件。 这标志着浏览器完成对HTML的解析并且DOM树已准备就绪的时候。 可能仍然缺少阻止JavaScript执行的元素，因此浏览器无法移动到呈现页面。
• 最后，在图片的右下角，您将看到domContentLoadedEventStart事件。 至此，DOM准备就绪，没有样式表阻止JavaScript执行，这意味着浏览器现在可以构造渲染树了。 例如，这也是在触发jQuery的$(document).ready()函数时。

如果domLoading和domInteractive之间的时间较长，则表明该页面上HTML结构可能太复杂了。 另外，如果浏览器花很长时间才能到达domContentLoadedEventStart ，则可能是JavaScript或CSS文件阻止了关键的渲染路径 。

为解决此问题，请确保在可能的情况下异步加载JavaScript文件，并且不要加载过多的单独CSS文件（如下面的屏幕截图所示）。

由于浏览器可以一次加载有限数量的文件，因此每个文件（无论大小）都会增加总加载时间。 同样，对于CSS文件，浏览器必须等待它们，然后才能呈现页面内容。

要解决此问题：

1. 分析跟踪以查看是否有不必要的文件正在加载 。 在我的网站上，我发现我的某些WordPress插件正在排队不必要的，几乎为空的样式表文件，每个文件增加的加载时间比其大小所期望的要多得多。
2. 考虑每个页面上是否都需要您的脚本和样式表。 通常，仅在网站的一个页面上需要脚本和样式表时，便会在每个站点上包含脚本和样式表（例如，您无需在购物车页面之外加载与信用卡处理相关的脚本）。 另外，请记住，在浏览器可以呈现页面之前，它需要解析CSS：简化CSS标记可以更快地处理并减少显示页面所需的时间。
3. 尽可能合并文件 。 在我的网站案例中，最大的加载文件优化是安装一个WordPress插件（ Autoptimize ），该插件将所有排队CSS文件合并为一个文件，并将所有JavaScript文件合并为一个。 这样，访问者现在不必加载17个单独的文件，而是现在只需加载2个。

检查加载资源需要多长时间

DOM处理阶段结束后，跟踪将移至下一个跟踪，即Page Load 。 该阶段将一直持续到HTML标记中引用的所有资源都已加载并且页面已准备好为止。 届时，您将看到一个显示事件domComplete的圆点，并在domComplete不久显示pageshow 。

如果此阶段似乎需要很长时间，请遍历其中的资源，看看它们是否在减慢页面的呈现速度。 尽管DOM处理不会阻止图像，但是加载图像可以抢夺更重要的带宽。 当然，等待很长时间以加载图像并不会使您的用户满意。

例如，如果您查看上面的图像，它显示的杂志封面的加载时间超过了半秒。 对于稍后在某处显示的照片（例如，当用户已经在阅读内容的文章内）这可能是可以的，但这是页面加载后显示的第一件事。

要解决此问题：

1. 遍历您的资源并在可能的情况下优化图形。 通常，最简单的解决方案是最有效的。 因此，在执行其他任何操作之前，请遍历会话跟踪以查看哪些文件需要花费很长时间来加载。 然后，检查这些文件是否可以优化。 不要依靠浏览器来调整图像的大小，而是提前将它们缩放到正确的大小。
2. 仅当用户需要查看大图形时，才使用延迟加载来加载大图形。 在包含大量图像的长页面上，只有在页面准备就绪后，才可以使用延迟加载脚本（例如lazy-load-xt）很好地加载某些仅在滚动页面时才出现的图像。 但是，请不要太过分：“折叠上方”显示的图像最好尽快加载-毕竟，我们希望尽快显示页面的第一个可见部分。
   
3. 考虑使用CDN。 CDN是一项额外的投资，但是如果您为大量的访客提供服务，则值得考虑：通过让用户从附近的资源下载资源，可以大大加快资源的加载速度。

将封面图像优化为首页上实际使用的尺寸后，加载时间减少到161毫秒（尽管值得注意的是，不同的会话跟踪记录彼此之间不是直接可比的，因为它们记录在不同的环境中）。

寻找缓慢JavaScript块

当您继续向下滚动轨迹时，即使浏览器仍在加载资源，您也可能会发现带有红色边框的事件，例如：

红色边框表示该JavaScript函数被阻止了33毫秒以上。 浏览器的文档解释说，这是因为比此更长的回调在被快速连续调用时，会将帧速率降低到每秒30帧以下，这对于人类来说似乎是个缓慢的速度。

因此，当您发现这样的事件时，请检查您JavaScript代码并查看内部发生了什么。 知道您的代码会有所帮助，因为这些块并不总是具有很好的描述性。

还请注意，此类缓慢JavaScript块不仅限于初始加载，还可以在会话跟踪中的任何地方发生，具体取决于应用程序触发器触发JavaScript。 因此，请确保从头到尾遍历整个跟踪过程，以免丢失任何内容。

步骤4：分析AJAX请求

在现代Web应用程序中，从优化初始页面加载到执行服务器请求而无需重新加载页面，AJAX请求可用于各种各样的事情。 因此，根据您的体系结构，您可能会在会话跟踪中的非常不同的地方找到AJAX请求。

在会话跟踪中，AJAX请求显示为蓝色条，如下所示：

在我们作为优化步骤的示例使用的页面上，访问者看到的元素之一是从Tumblr博客加载的视频和照片流。

使用Tumblr API加载流时，它会为每个页面加载增加大约一秒钟的时间。 这就是为什么我决定将其加载仅在页面完全加载后才进行的原因。

像这样使用AJAX意味着，当站点到达DOM Completed步骤时，站点并未完全加载。 为了强调这一点，会话跟踪添加了一个页面加载阶段，称为Waiting for AJAX 。 根据用户使用AJAX调用的情况，您可以决定是否需要等待这么长时间是一个问题。

在会话的稍后阶段，与加载文档无关的事件触发的AJAX请求不会计入“等待AJAX​​”步骤。

使用AJAX页面分析您的AJAX请求

如果你认为你的AJAX请求之一，无论在页面加载或其他地方在该网站的执行，可能是时间太长，或者如果你只是好奇发生在你的AJAX请求上的AJAX的项目申请点击左侧菜单。

我的示例应用程序没有使用很多AJAX请求，因此New Relic回调进入了列表的顶部。 实际上，我前面提到的AJAX请求仅在列表中排第三： GET /*. 。

单击请求的名称将打开一个视图，其中包含有关所选AJAX请求的更多信息，包括花费在该请求中的时间，发出请求的频率，返回的错误列表以及在该请求中传输的数据量。典型要求。

Analyzing this data, you can decide if there is something you want to do to either fix or optimize the AJAX request. In our example's case, everything seems to be running rather smoothly, so no immediate action is needed.

As a server-side action, what happens inside the AJAX handler isn't visible in Browser. For this, you can check APM—or simply jump to the code to see if there's something that could be optimized in it.

Step 5: Repeat

We have now gone through one session trace, and depending on how optimized your site was to begin with, you may have written down just a few ideas or even a full page of candidates for things to fix. Now, to make your hypotheses stronger, the next step is to start from the beginning: pick a second session trace and use it to see if the same issues are visible in it as well.

Then, go ahead, and fix what seems to be wrong!

How to Spot and Fix JavaScript Errors

We have now looked at optimizing your page loads and AJAX requests. But sometimes, the issue isn't a slow loading time but a JavaScript error that prevents your user from using your pages the way you have intended them to be used.

Luckily, Browser can be used for this as well.

Step 1: Pick a Practical Error to Fix

Whether you are looking to fix a bug reported to you by a customer or just want to make sure everything is running smoothly, the first place to look at when it's time to fix JavaScript errors is the JS Errors page.

This page is very similar to the Page Views page we saw earlier.

On the left, you'll see a list of the errors that have happened on your visitors' machines during the selected time frame. If you don't see any—or if you want to filter out older errors—adjust the time frame to something that works well for your needs.

Now, looking at the error messages, you'll quickly notice that some are much more specific than others.

So, to make the most of your development time, try to pick something that happens a lot (is high on the list) but is also descriptive enough so you can actually find and fix it. A common error such as "Unexpected identifier" that can be raised because of many different reasons is not a good choice.

When you see something that looks promising, such as the third item in the list above, "thas is not defined" , click on it to see more information about the error. The Overview tab includes a graph showing the number of page views affected by this error as well as a graph with the total rate of this error over time.

Following the two graphs, there's Browser Breakdown, a section that shows the distribution of browsers affected by this error. This is useful for figuring out if this is a browser-specific issue. Finally, at the end of the tab, whenever applicable, there's a list of session traces including this error.

In all, this looks like a good candidate for an error to fix: the error is happening rather often, it has a descriptive error message, and it can even be found in a Session Trace.

Step 2: Look at the Stack Trace

On the second tab, Error instance details , you'll find more information about the error, including the full error message, the URL on which the error occurred, as well as a stack trace if there's one available.

In this case, the stack trace is very descriptive and so we can fix the bug simply by looking up the JavaScript code at the point referenced in the stack trace:

btnHover/<@https://bread-magazine.com/wordpress/wp-content/themes/fourplatform/library/js/scripts.js:32:21

m.event.dispatch@https://bread-magazine.com/wordpress/wp-includes/js/jquery/jquery.js:4:8497

m.event.add/r.handle@https://bread-magazine.com/wordpress/wp-includes/js/jquery/jquery.js:4:5235

The solution to this bug was simple: On line 32 of the scripts.js file mentioned in the stack trace, there was a typo in which I had typed thas instead of this .

Step 3: Reproduce on a Development Server and Fix

In a more complex case, where the session trace is not quite enough to show you where the error occurs, you'll want to find more information on when the error happens and how you can reproduce it on your own development machine.

To do this, first check to see if there is a session trace attached to the error. Looking at one can be a valuable tool that will give you insight on where the error happens in the application's flow and what the user did before the error was triggered.

For example, in this case, I can see the error happening three times in a trace. Each time, it takes place right after mousing a.button.btn.btn-primary.dark —that is, moving the mouse over a button. So now, even if I didn't have the stack trace, I could just run the app and bring my mouse over one of the buttons to see if I can trigger the error.

Once you have found the error, continue just as you would with any other JavaScript bug. Then push the fix live, and after a while, come back to see if the fix did its job.

结论

We have now explored how you can use New Relic Browser to find the points on your web site or on your web-based application that frustrate your customers, both errors and times of slow loading.

In addition to what we just saw, New Relic Browser has tabs for looking at geography and browser data and how it affects your page's loading times. This can be useful information when you are considering CDNs or serving your data from a specific location.

Now, give Browser a try to find your own slow or failing actions.

Then, optimize your site and bring in more, and happier visitors!

翻译自: https://code.tutsplus.com/tutorials/how-to-use-new-relic-browser-to-improve-your-web-apps-user-experience--cms-24766