These are the top 10 snapshot results. To see complete query results, hit 'Return'.

Webinar:

Solving Real Problems with New Relic Browser
[A Practical Guide]

 

Data is great, but only as good as your ability to take action on it. Join Jeff and Parker to learn why front-end performance matters and how to use New Relic Browser to take meaningful steps towards faster page loads and better user experiences.

View the webinar!

In this webinar, we'll discuss:

  • The data behind why front end performance matters

  • Types of optimization that can be made in the front end

  • Types of optimization that can be made in the front end

  • Where to begin in New Relic Browser when you are ready to optimize

  • How New Relic Browser Pro features take you beyond the page load



Full Script

Solving Real Problems with New Relic Browser

Shay: Hi, everyone. Thanks for joining today's webinar, Solving Real Problems with New Relic Browser. We will hear from Jeff Martens, Product Manager at New Relic, as well as Parker Edwards, Enterprise Sales Engineer at New Relic.
Before we start, just want to give you a few housekeeping items. Today's webinar will be recorded. The recording will be sent to you shortly after the presentation.

There will be time reserved at the end for question and answers, so be sure to place any questions you might have in the questions panel of the GoToWebinar control panel. Now, I'll hand it off to Jeff.

Jeff Martens: Thank you so much, Shay. Welcome, everyone else to our webinar on Solving Problems with New Relic Browser, excited to have everyone here, today.

A quick rundown of our agenda, we are going to do some really quick presenter introductions. We're going to spend just a couple minutes on why New Relic believes real user monitoring matters.
We'll tell you about New Relic Browser for those of you that are not familiar with it, and then we're going to jump into doing a live demo.

That's going to be exciting because we're going to look at production software and see if we can find some problems on the fly, with an audience of a couple of hundred people watching. Let's jump in.

My name is Jeff Martens, I am a product manager here at New Relic, I work our new Relic Browser product line, which provides client side performance monitoring for web applications. I've been at the company for a little over, about a year and a half, a little over. I've out of our Portland, Oregon office, where we do all of our engineering.

Prior to working on New Relic Browser, I was on New Relic Insights, where I helped launch the analytics product, and lead it's growth. I'm excited today, to be joined by my friend and my colleague, Parker Edwards. Parker, are you on the line?

Parker Edwards: I am. Hey, Jeff, and hey everybody. I'm Parker Edwards, I'm from our enterprise sales engineering team, down in San Francisco. I originally hailed from our Portland office, where I worked on our support team.

I've been with New Relic now, for a little over a year. I'm excited to demo New Relic today and show you guys how we can use browser to solve some real problems.

Jeff: Thanks for joining us, Parker. Really excited about working with you on this. Let's jump in to the content for today. Let's start out by talking about why real user monitoring matters. I'm going to start out and give you one of the most obvious phrases that you've probably heard throughout your life. That is, time is money.

As cliché as that may be, it applies to web development and applications running in the browser. Here's what we know. Research has showed us that for every second of page load time, you'll lose on average of seven percent of your business.
When you dive into the data, what you find is that's a pretty linear curve for the first four seconds.

After four seconds waiting for a site to load, you've lost in the area of about 25 percent, a quarter of your users before your page is downloading if it takes longer than four seconds. You'll continue to lose people after that four seconds, but it drops off a little bit for every second not quite at the level of seven percent.

It goes even deeper than that. We know that nearly 50 percent of users of web applications expect the page to load in two seconds. They may stay on the page longer, but they're frustrated if it takes longer than two seconds.

In fact, about 30 percent expect that to happen in just one second, and 18 percent of users expect an instantaneous page load. When I looked at the data I found this interesting because in 2009, virtually no one expected instant page load.

Here, when this research was conducted in late 2014, it had jumped from zero percent expecting instantaneous page load, to about 18 percent. Quite a change.

Now, to put that in context. If you work on application that generates let's take some easy math $1.2 million a month in revenue, if that website would take one second longer to load, you could easily say that you're losing a million dollars a year in revenue because of a slow web application.

Those are real dollars behind this. That's why I used a very cliché but true term, time is money.

Now, I have a question for you. This is just a question for you to answer in your head. I'm curious what percent of user wait time is because they're waiting on client site code to load. As you think about that put a number in your head and in the next slide I'm going to tell you what that number is.

All right, everyone have an answer? If you want, you could put it in the chart so we can see how close your guess is. The answer is that 90 percent of the time users wait on a web application, it's because of client site code. We know this at New Relic, because we monitor hundreds of thousands of web applications.

We spend sometime in late 2014, taking a look at where time was divided. We did this in preparation for our launch of New Relic Browser our real user monitoring. By looking at anonymous aggregated data across hundreds of thousands of web applications, we found the average to be 90 percent.

In some cases, some of our biggest customers that have really optimized their back end they can see 95 percent or 98 percent of the wait time based on client's cycle. All of this is why New Relic believes that real user monitoring matters.

Let's talk a little bit about what we've done to address this problem. In late 2014, New Relic launched New Relic Browser. It's real time, real user monitoring from the end users that are hitting your production code.

We surface not only page load performance which is effectively table stakes in the monitoring space, but we've gone further and we collect JavaScript errors, we monitor your AJAX performance.

We've introduced a really exciting feature called browser session traces. For you to dive into these features a little bit more, I mentioned the page load time which has become a standard than any modern tool used often for finding code.

We're breaking it down by actionable segments not just the time the page took to load, but how much of that was network time, how much of that time was down processing and the rest in page ripping.

We can tell you that by browser name, browser version or even by country, city and there are some of our new features which are done at the top level.

One of the other screen shots here on this page, you'll see our browser session traces. This is an exciting feature that's a lot like having ComDev tools, but for your remote users.

Imagine being able to look over the shoulders of your users anywhere in the world accessing your application and look at their ComDev tools. You can do that remotely in New Relic browser as a SaaS offering.

Next up is some of our most valuable features are JavaScript error reporting where we're capturing all your JavaScript errors, bringing them together into groups so you don't have to go through them one by one. Telling you the rate and frequency of them happening, but also providing a stack tray so you can go solve that problem without wondering what's really behind it.
Finally, our AJAX performance. We know that web applications today are interactive and they do much more than just load static HTML. They're making calls to the back end to provide a dynamic and interactive experience for your users. We're telling you where time is being spent and helping you improve those connections as well.

Now we're getting into the mid of the webinar. Let's talk a little bit about how to solve an actual problem with New Relic browser. We've done webinars in the past where we've shown you what New Relic browser is, we've shown you how you can use it with other New Relic products like New Relic APM and New Relic Insights.

We want to spend some time today, trying to solve some problems. I give you tools that you can use right away whether you use the Relic browser, or another finer user monitoring tool and start making an impact your users will notice.

What I would like to do is give you a simple framework of how to do that with Relic browser to show browser and the features we offer, and then I'm going to turn it over to Parker to walk us through some real life examples.

You'll see on your screen that the framework that we suggest centers around our session trace feature. This is the ability to look at every single asset and element in the page load, and then everything that happens on the page after it's loaded while your user is either viewing it, or interacting with it.

We'll capture all the assets, all of your JavaScript. We'll call out slow executing JavaScript, we'll call out JavaScript errors or even show you where an AJAX call is causing the page to not be fully loaded, because it's waiting on a response.

The trick is to use this session trace feature with the other features in New Relic browser. We will link two in front session traces with our page load performance that breaks down page load by URL. They will also link to it as two are from our AJAX and two are from our JavaScript errors.

You can enter New Relic browser, and go right to a session trace and then figure out JavaScript errors, AJAX performance or page load optimizations to make.

You can enter New Relic browser, and go one of this other three features like JavaScript errors, find a group that is where the error has happened frequently and then jump into a session trace to see when it's happening and what is going on in the page load, or the user experience and the time leading up to that JavaScript error.

That's what we would like to show you today. I am going to turn things over to Parker to walk us through a few of this. Parker, you're ready to do that?

Parker: I am. Thanks Jeff.

Jeff: Then I will take off my screen.

Parker: Thank you again, Jeff. I'm glad to be here today. Just for some context before we jump in. What is a good webinar without some good data? I thought, "What's the best data we could look at?"and that' s our own. Just for some context, we'll actually be looking at our staging environment, which is where we use New Relic to monitor New Relic.

If you come in and you use our browser tool or any of our other tools across the platform we capture that data. Because it's important for us to be able to monitor and solve problems around front end performance for our users. When I navigate throughout the webinar you'll see some data. I wanted you to have the context.

First things first. We're going to go in and we're just going to quickly look at some of our historical data here and try and find a good place to start. I like to talk about browser and talk about these problems in a stream of consciousness fashion. You'll notice, first things first, we go to our overview page for our application, and even our overview page shows just a wealth of very valuable information.

As a front end developer coming to this page, the first thing that catches my eye is the huge spike in page load time. If I come in and I see this huge spike I might think, "What caused this? Ultimately what was the impact of this spike on our end users' performance?"

That question can be answered for us. Right over here we see our AppDeck score, which is our measure of user satisfaction, has gone from 0.95, which is excellent, all the way down to about 0.23. That's an unacceptable level for us during this time. That tells us that during this time frame, only 23 percent of our users had an acceptable user experience.

What's funny is, as we break down through this response time we see this huge spike in requests queuing. That corresponds with a drop in throughput, but also a huge spike in JavaScript errors, where we're sitting right around one percent all the way up to about three and a half percent, and then in Ajax response time, where we're on about 1 second all the way up to 12, almost hitting 15 seconds of Ajax response time.

This is something that I want to dig into. I want to go ahead and try and find out what caused this issue, and, maybe, what was the impact of this on our user experience and how can I fix this going forward?

The first thing I'm going to do is look at this "Compare with Yesterday and Last Week"box. It's this little innocuous box down in the corner that allows us to see what our historical performance is.

We can actually go in and look and we see this spike and we can actually see it in line with the same time frame from last week, or even yesterday. We can see that this is not a spike that occurs often. This is something that is an anomaly for us. We can see our AppDeck score and everything.

We definitely want to address this. We're going to do that by going into Page Views. We go into Page Views and the first thing we'll do here let me refresh is look at our interface tools. We see again the response time spikes. The first thing that I want to do here is zoom in to this spike. This is a pretty commonly known feature, but we don't advertise it super well so I always like to bring it up.

If we want to make sure that we're always looking at the same set of data, New Relic gives us the ability to do that. We just zoom in. You can see I just click and drag over the chart. That will take all of the data that I look at on this page as well as all as all the data that I look at from this point onward and zoom it into this context.

As I go in and make sure that I'm looking just at this performance issue, you'll notice that our time ticker is changing to reflect the time that I've selected in the chart.

Now, instead of looking at the last three days' worth of data, we're actually looking at one hour ending Monday at about 20:28 Pacific Time. This allows us to go forward with the confidence that we're looking at the right data and that we're going to be looking at data that affected our users during this period of odd behavior.
There's two other things that I think are really important to note here on the Page Views side, and that's up here, this Sort By box. By default, when you come to the Page Views page, you'll notice that it shows you the percentage of total page load time. Which is great. We're actually going to use this moving forward today in the webinar.

But I also want to mention some of the other options here. Of course we have throughput, but then in between those we also have average page load time. If we click into this, this lets us see. When we were on our overview page, we were able to easily see that historically we're sitting right around three seconds for our page load time. That's great for us.

Like Jeff mentioned, we have statistics that show us that three seconds is unacceptable amount of page load time to most users.
But what's interesting is that if we can go in, we can see that there are quite a few pages that are above three seconds. This is a great way for us to say, even if we aren't looking at a period of poor performance, it's a very easy way for us to go in to the New Relic interface, and find pages where we can make an impact.

In this case, though, we're actually going to look at percentage of total page load time. This is a quick way for us to see where we can make the most impact in the shortest amount of time. You'll notice that leading this is our public charts page. Just for some context, if you were to go and create a chart and make it publicly embeddable, within any place in New Relic, it would appear on this page.

We can see that we've got pretty consistent throughput of an average of about 400 pages per minute, but that's taking up almost 37 percent of the total page load time across all of New Relic. This is definitely a place where we want to dig in and we want to start to try and discover some problems here.

We'll note really quickly down at the bottom that session traces are automatically brought right to the top of the list that fit this criteria. Like Jeff said, we have a great framework in place for solving these performance problems. Where we're going to start is in Page Views. We find some pages that we want to identify some poor performance on. We're actually going to jump into Session Traces to get that granular, specific data on how we can fix these issues.

In this case I've actually gone ahead and pulled up some session traces that have some interesting data for us to look at. In this case you can see we're looking at a public charts page and we see it's running on a Windows Chrome user. They're running on the newest version of Chrome, version 44, and some stats pop out at me immediately.

The first is that we took 9.4 seconds for this page to load. That's not great. On average we're supposed to be sitting right around three seconds. This is definitely something that falls outside of the norm.

If we go forward we can also see that we spent almost 23 seconds waiting on AJAX. In today's environment where we're using AJAX to really pull dynamic information into our elements on the page, we want to make sure that that AJAX is responsive. That's definitely not the case here.

The first thing I'm going to do is dig into this AJAX. We can see if we just click on "Waiting on AJAX" it's going to take us right to the problem in this case. We've got this AJAX call that goes to one of our services on the back end. Right off the bat we can see this single AJAX call took 14 seconds to process. It returned at 200, which is great, ultimately, but our user still had to wait almost 14 seconds for that data to load.

We're going to go in and we're going to click this "Full View Details" button. We went from a very high level down to a low level, so we're looking at a specific instance of this page view and now we're going back to the high level.

We can actually see what the AJAX performance of this particular call was like historically. You'll have to give me just a second here on our staging environment while this loads up. I might actually have it...I do have it pre loaded here. We can actually see the historical performance of this AJAX call over the period of time for this performance issue.

We can see for this AJAX call, we're sitting right around 25 seconds in terms of total time to process this data. That's not great. This is something immediately that we want to bring to the attention of whoever owns that endpoint, whether it's internal or external, so that they can be aware of that problem and fix it.

What's also worth noting here is that if we go down to status codes, this gives us a very easy way to see and identify where the problem was. In this case, we can see we had a lot of 502 errors on this AJAX endpoint.

This is a great way for us to see and identify that the problem happened to be a server error on the back end, but it's affecting our front end and our users that are coming to our page in a very significant way. Now, with the power of New Relic, you can take this information, you could save it to a note, send it along in an email or however you want to get this to your back end developers.

In this case, this is an endpoint that we own, so we can send this on to our back end developers so that they are aware of the problem and they can fix it. Before we do that, though, we might want to verify that this wasn't a one off problem and that maybe it affected different users in different environments.

What I did is went through here...it allows us to see, again, session traces within the time frame of the error that we're looking at, thanks to the fact that we zoomed in using the time picker. We can actually see now that we're on a Linux Chrome environment using version 47.

It's really hard to get different environments than going from Windows to Linux from a completely different user visiting a completely different page within that segment, and we can still see that a call to that same AJAX endpoint costed our users about 19 seconds.

This is great data for us. It allows us to take all of this evidence, bring it to our developers, or to whoever owns that AJAX endpoint, and solve that issue, so that the impact on the front end can be positive and quick for our users.

We'll go on, but before we do, I want to just also mention, this is a great opportunity if you have any questions about anything we've brought up so far, or anything that you have questions about regarding New Relic Browser, go ahead and enter them into the GoToWebinar control panel. We'll be addressing those at the end.

I'm going to jump back into our session traces. This is another session trace that I've found that has some pretty interesting data for us. You'll notice this is where a user went to their account page and went into the servers page. For those of you that don't know, we have a great server tool.

They went to this page on a Mac Chrome browser running version 47. While they didn't have a particularly bad page load experience, we can actually note that as we scroll through the session trace, we see all of the back end processing time all of the way down to all of the elements that they were looking to load.

Again, up until this point, we've had pretty good performance, but then you'll notice that we make an AJAX call. Immediately, we overload the user with errors, so we've got about seven JavaScript errors, and they immediately leave the page. We see the beforeunload event, and then finally the pagehide event. We can go in and see some of these errors.

This is where New Relic Browser really shines. It allows you to see and quantify the impact of these errors on the performance. As you can probably guess, this is going to lead us very nicely into our JavaScript errors. I'm looking at a couple of these, we see a bunch of, "Onload event is not a function."

That's not great. We should have a function for our onload event. This is definitely something that we're going to want to dig into a bit further. The power here comes, again, from our click through visibility. We can go into our error and click on, "View similar errors."

It's going to take us out of this session trace and into our JavaScript errors. It's going to pull up this particular error and show us some additional data. I have this here...again, in our staging environment, things sometimes perform a little bit wonky, but I have that pulled up beforehand.

We can see that exception, we can go in and see additional session traces that are applicable to this error, we can see a browser breakdown so we can see what environments this is affecting in terms of user, and we can go over to our error instance details where we can see very granular and well defined attributes that can help our developers find this problem and fix it moving forward.

I'm sure I don't have to tell everyone on the phone that JavaScript errors are essentially black holes for users. If you don't collect these errors in a QA environment or a similar environment before they hit production, it's almost impossible to find these errors later.

It's important to have a tool like New Relic in place that can catch those errors, bring them to you and process them so you can quantify the impact on user experience like we just did with session traces.

We can see here that we've got the stack trace for this error. I clicked on a different one there, the "JQuery is not defined" that occurred directly beneath that, but we can go through and we can see the browser, the user agent type, the URL that the user visited. Again, this is almost a treasure map for our developers to be able to go and replicate this issue and try and solve it.
We're actually able to go all the way down to the line number for this error, so we give you the stack trace for this JavaScript error. Now you can take all of this information, throw it into your IDE, and fix it without ever having to go and actually stand over your user's shoulder to try and get them to replicate that error.

It's a very powerful tool. That's a great way to look at JavaScript errors. We can go back and we can see again, it looks like that servers page that we looked at, we have another user that visited a completely separate page where they were impacted by this error.

We can go in and, if we wanted to, we can look at this from a high level down. In this case we can go in and see some of the other JavaScript errors that are affecting our site. We can go from here and go down into session traces again.
We can see this is something that's overwhelmingly affecting our Chrome users, with a little bit on Firefox, Safari and Internet Explorer. We can see those error instance details again, but the power comes in when we go through into session traces and find the impact on our user experience.

I'm going to go through and navigate back to session traces. I'm going to show you a couple of other ones that are pretty interesting to us. This is our application setup page. I'd like you to imagine that you have a page like this.
Just for some context, our application setup page is a page that is going to be one of the first that they see when they visit New Relic. They have heard about us, and they have decided to come and try out APM or one of our other products. They come to our site and they hit this setup page.

We want this page, more than anything else, to perform well for our users. If this doesn't perform well, that leaves a negative impact on those users and their concept, definition and perception of New Relic. We want to make sure that performs well.
Right off the bat, again, we can see we're hitting about 6.5 seconds in terms of page load. This is something that we might want to deal with. We can see that the user actually did start interacting with the page, but let's dive in here and see if maybe we can find out why the page took so long to load.

If we go down we can start to see some of the events, just like we have in all of our other session traces. Something will jump out at you immediately as I'm scrolling down here, and that's these huge, big red bars. If we go through, we see a lot of these other JavaScript calls that have been flagged because they're slow execution.

This is a great concept that New Relic brings. We'll actually highlight some of these performance issues for you as you're diving through session traces, so that you don't have to hunt around and find them yourself. Some of the things that jump out at me. A lot of these are coming from Wistia. For those of you that don't know, Wistia's actually our video provider.

It's a great video provider. They have a JavaScript library that actually loads in an iframe on the page and plays that video. In our case, and if you were to go to rpm.newrelic.com, navigate to applications/setup, you'll notice a very well put together video that shows you how to actually use New Relic and get started.

In this case, it looks like we have a bunch of instances where this iframe that's not owned by New Relic, but rather owned by Wistia, was performing poorly. We had some slow JavaScript execution. We've got a couple of different calls that took almost two seconds to load and a couple that took a little bit under.

All said and done, we're looking at about six to seven seconds worth of slow JavaScript execution that's actually outside of our control. You might be thinking, "What good does this do me as a developer?"

This data empowers you, it's very granular and specific data, it will empower you to take this to the third party provider, in our case Wistia, and work with them to try and solve this issue moving forward. Now, it's not a he said she said type of debate or, "I think I might have noticed this type of incident on our page."

You can have granular, specific data to take to those providers to say, "Your tool had a negative impact on our users' performance. This is how we've quantified it, this is where we found it. Is there anything you can do to help us fix this moving forward?" It's a great tool to identify problems that might not even be within your realm of control as well.

We'll move on here into our last session trace that I wanted to look at. When you're starting to get into diagnosing and enhancing your front end, this is a great place to start, and a place where I would expect you to find quite a few issues, or I guess bugs, that you could fix moving forward to really make a positive impact on your users' performance.

If we go down, we'll notice that this page again took about 6.37 seconds to load. That's not great. They waited on the page for about 48 seconds to interact. This can tell us maybe they were reading content on the page or maybe they had the page open in the background before they actually wanted to interact with it.

The cool thing here is that we can actually see the elements that caused this page to load. Even in our DOM processing we took about 4.2 seconds. That's what we're going to dig into in this instance.

These are the elements that make up our DOM processing. You can see we've got quite a few that take almost a second. We've got these PNGs, so it's actually an icon pack that took almost a second, 800 milliseconds just about, to load this PNG. That tells us that maybe this isn't a well optimized asset or resource.

We can also see some other files here. We see some JS that took quite a bit to load, we see a CSS file that maybe could be made smaller or put into a CDN to be more easily accessible. You can see in this case we're actually pulling this from our local servers so we could stand to put this on a CDN or something to improve performance moving forward.
These are really great small tweaks that will add up in the long run. You might think, "I could go through and optimize or compress our PNGs, but what's going to be the impact of that on our end users' performance?"

You can think about it this way. If you've got one asset that's taking 800 milliseconds to load and you've got throughput, this asset appears on almost every one of your pages and you've got throughput in the thousands, that adds up very quickly.
You could have an impact of almost hundreds or even thousands of seconds, just by fixing one or two individual assets that you uncovered using session traces in New Relic Browser.

Those are just a few of the ways that we can use Browser to jump in and find some of these performance issues across AJAX, across JavaScript, and even down to the individual resource and element levels. I'm going to go ahead and pass back to Jeff. I want to save ample time here for us to go through some questions and answers. Jeff, I'll pass it back to you. That's all I've got.
Jeff: Hey there. Sorry, I just realized I had my microphone muted. Thank you for that demo, that was absolutely fantastic. We appreciate you walking through this. I've been monitoring the GoToWebinar and we do have some questions that are coming in.
If you have any questions, we have three people here at New Relic monitoring the questions that are coming in so please type them into GoToWebinar and we'll start answering them.

The first question that I have from James is, he wants to know if New Relic Browser works with mobile browsers too. The answer is, yes we do. We work with really any client side environment. We have stated support for specific browsers and versions running on specific operating systems which you can find in our docs. That does include mobile.
You'll see that in the feature in New Relic Browser there's a left hand nav, and there's an item that says browsers. If you click that we'll show you your page load breakdown for different browsers, different browser versions and then we surface those throughout the product.

We saw Parker showing us some session traces. We'll state the browser name and version there. You'll notice frequently, many of them that pop up are mobile browsers. We treat that seriously. We know that traffic is moving mobile and we support it.
Let me find another question here. We have one...let's see, sorry. I have to find it here. Kumail asks, "How can our session traces work with single page apps, like apps built in Angular?" Currently, the way our session traces work is they're anchored on a page load.

If a user loads a page from server side, we can begin capturing a session trace. We will monitor the user's interactions on that page until they leave and go somewhere else. In a lot of cases, that's going to include interactions that happen after the page load thanks to a single page app environment.

We are currently working on what we call first class single page application monitoring, where we will begin to capture route changes that are not associated with an initial page load, and surface much of the same information that we do in our product today on page loads.

The answer really is, we do some monitoring of single page apps but it's currently anchored to a page load. Later this quarter, we will begin to roll out our first class single page app monitoring that goes far beyond just a page load. We're excited to show that to you here in a bit.

Let's see some other questions. Parker, if you see any you'd like to address, go ahead and jump in while I look at the list a bit.
Parker: Certainly. I've actually got one from Keith here in regards to JavaScript errors. "Do those tell us the ID of the page or container where the JavaScript was executing?" Absolutely.
If you navigate to any individual JavaScript error, you'll see not only some of that useful data within the stack trace, you can also see, of course, the URL where the page was, as well as the name and identifier of the JavaScript itself.

Parker: I do have one other question here that came up. That was, in terms of browser, can it interact with other tools, so other tag based tools to monitor maybe marketing impact, specifically Google Analytics? In that regard, absolutely.
We definitely recommend if you're going to be putting New Relic Browser on your application, to put it high up in the head of the page. That way, it can accurately measure the performance impact of all of the other JavaScript based tools that you're running on your site. It definitely plays well with others.

Jeff: Related to that, we've had a variety of questions coming in about what New Relic browser supports. Do we support ASP.NET, do we support [inaudible 36:05] applications. Parker, do you have any comments on how we work with different frameworks and different technologies beyond what you've already...

Parker: Absolutely. From that regard, we're pretty platform agnostic and framework agnostic as well. As long as the elements are being executed on the page...One notable exception would be SWF or Flash applications. Web 2.0, it's really built to interact with those and not care really about what frameworks or platforms they're built on.

ASP.NET, absolutely. I'm not familiar with the other framework you mentioned, but the great news again about New Relic and coming from support, I have to give support a plug here they are absolutely willing to answer any questions you might have if it helps you with getting implemented if you'd like.

Jeff: Here's another question I wanted to address. Does Browser require app server plugins, or do we simply embed a script in the site pages/content? There's a variety of ways to instrument New Relic browser. The easiest one is if you use New Relic's APM product, which we internally call app server.

If you're using a language agent with your server side application, there is simply a toggle that says, "Include real user monitoring." If you check that box, we will automatically inject the JavaScript for you and there's no additional instrumentation required.

If you don't use New Relic APM on your application server, or if you use it but you don't want to do the auto injection, we also offer a JavaScript snippet that you can copy and paste into your application to do it that way. We try to make it really easy and give you a lot of control over how you instrument and let you do it in the way that works best for your application.
Parker: I've got a couple of questions here, Jeff, that came in and I'd love to address. The first is a great question. The user speaks to a specific use case. Let me read it here.

They have a specific client they're trying to detect issues for and have to spend the time connecting into one of their individual machines to collect data about their connection. Could that be supplemented or replaced, and can we identify those individual users environment?

To answer that question, absolutely. Out of the box, the data I showed where we collect user agent data, we collect geographic data which we didn't get into today. We collect a large amount of data out of the box. Using our analytics tool, Insights, which is something that comes with Browser, and it's included in the platform, you can go through and ask those questions.
Let's say you wanted to see the performance impact specifically on any individual page for our Linux users. You can do that. You can ask that question and see the impact with New Relic Browser and Insights. The other side of that is we also have the flexibility, and give you the ability, to add additional attributes that you'd like to capture.

We've got a really cool API, very well documented, on docs.newrelic.com. You can actually go in and record additional attributes that you want to send to New Relic as a result of those page views. Let's say you wanted to record the session IDE or the user IDE for a logged in user. You can do that. That then becomes a filterable attribute within Insights.

This is something that's very well documented on our docs site. We might even speak to a particularly similar use case there. I definitely refer you there so you can learn more about that, but absolutely, that's something that we can help you with.
There's another question that I'll rapid fire through that came in. "Do you use sampling or do you collect all users' data in regards to performance and overhead?" Again, we have a great doc on performance concerns on New Relic browser. We've had thousands of users use the product with very...I've not experienced any issues with overhead. We document that very well on our docs site.

To answer your question about sampling, no, we do not sample. Any time a user visits your site, they're going to run through that script that Jeff mentioned, and they're going to send that data to New Relic.
In terms of session trace data, that specific granular instance is "Sampled," to an extent, more for the ability to allow you to quickly sift through them in order to see the ones that jump out in terms of performance issues. Great questions from Dave and Keith.

Jeff: I'm going to answer a couple more here. We have one question about how New Relic licenses New Relic browser. That's done by page views per month. That's currently based on the number of traditional page loads your application does in a month. Our smallest plan offers 500,000 page views per month.

You can find all of that out on newrelic.com, either under the product pages and then selecting "Pricing," or just go to the main Pricing page and we show you the options there.

A second question that I wanted to answer is about detecting network latencies. There's a couple of parts to this answer. The first is that New Relic Browser has always shown you the request queueing, web application time and network time for certain applications, depending on if you're using the New Relic APM product or not.

Where New Relic tends to shine is when you're using our APM product on your app server but also our real user monitoring client side. You probably noticed, when Parker did his demo, the page load times were broken down by request queueing, webapp time, network time and then the client side code. We're going much farther than that.

We announced a new feature at our New Relic FutureStack conference back in November of 2015 called "Filterable Geography," or some people put it "Geography Analytics." We re imagined our geography feature in real user monitoring. In the past we just showed you the breakdown of page load time by country or region.

We now go even deeper, and we're bringing in network characteristics. We will tell you how long the DNS lookup took, how long it took to establish a connection, how long the secure portion of that connection lookup took. We're doing that, and we're also allowing you to filter and facet it by autonomous systems.

In many cases, an autonomous system is an ISP, so you can say, "Show me how long the DNS lookup took for all my users that came to my application from Comcast." That's something that's currently in private beta.

In the next week we should get that into public beta for all users of New Relic browser, and you can start going much deeper than just the page load and look at how the network characteristics of your users is impacting the overall performance of the application.

All right, we've got a bunch of other questions here and frankly it could probably take us all day to answer every single one of them. Before we end, Parker, is there anything else we wanted to address, or do you think we covered it and we can take the rest of the questions offline?

Parker: Yeah, we could certainly take the rest of the questions offline. There are two things I'd love to just plug. The first is absolutely our docs site at docs.newrelic.com. We've got a lot of very well documented resources there for our APIs for the browser tool as well as all of our other products as well.

The second would be learn.newrelic.com. This is a tool that we actually announced at FutureStack back in November. It's a great tool. The webinar might go there, I'm not sure if it'll end up there, but we've got a number of great videos, great resources as well as links to some really helpful support pages for how to learn to use New Relic.
With that, I think that's everything I wanted to address, Jeff, and we can certainly take the incoming questions offline here and get answers to them today.

Jeff: Sounds great. Shay, shall we turn it back to you to end the webinar?

Shay: Yeah. Thank you guys. Just a quick reminder to everyone that the webinar recording will be sent out to you guys shortly. Thanks again Jeff and Parker for your time and thank you all for joining us. Have a great day.

Jeff: Bye bye.

Read more