Sessions is temporarily moving to YouTube, check out all our new videos here.

Going Beyond the Page Load

Richard Moore speaking at JS Monthly London in September, 2017
43Views
 
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

Watch how to use the New Relic Browser API to gain more metrics.


Transcript


Hi folks. Today I'm gonna be talking about Going beyond the Page Load. And, basically, how to utilise New Relic browser to extend the instrumentation that you have available to you. Before I dive into that, a little bit about me. My name's Richard Moore. I'm a Technical Account Manager at New Relic. So, I'm very lucky to be able to work with companies all over the globe, on basically getting up and running with New Relic. If you want to, you can connect with me on Linkedin, or you can go find me on Twitter. I don't really tweet much, I've got a fairly boring life, on Twitter. I'm also joined today by Cillian O'Shea and Chris Waynforth, who are also from New Relic. And, after this talk, and at the end of the night, we'll be available to answer any questions that you may have as well. So jumping in, just out of interest, how many people here actually are aware of New Relic or heard of them? Cool, okay, that's pretty good, okay. Good to hear. So, today, I'm not going to be giving you a sales pitch. I'm actually going to show you some cool stuff that we can do in New Relic. And specifically we're going to focus on two key things. I'm going to focus basically on looking at our Browser products and how we can use that to in line with Insights, to, basically, gain more than just the page load and DOM content loaded metrics. So, first of all, it's probably of importance to have a good understanding of what we currently do and why we do that, and actually why is that important. So what we actually do when we're working with our Browser product of the moment, is we connect into the Performance and Navigation API. We happen to also use the Resource Timing API, and various things under the hood of the Browser agent. And, what we're actually doing is we're actually timing all of the segments that are going to the delivery of your webpages. So specifically, we're looking at, for example, the ability to give you the DOM processing time, the time you've spent in page rendering. And at the end of each of these events you're going to typically have DOM content loaded happening at the end of your DOM processing. And you're also gonna have the Page Load Event faring after your page is basically loaded. These are, two pretty much industry standard metrics that you will probably be aware of in the delivery of webpages. However, obviously, there is a lot of other metrics out there that you can go after. So, I don't want to give you the idea that obviously these aren't important metrics because these certainly are important. When it comes to your applications going out into production and utilising those if you're working with a large organisation where you have an Operations Team or maybe you're in a Davos culture, you'll be responsible for your application. So when you see the DOM processing phase increasing within your applications, this is a good indicator to be able to track how long the DOM processing is taking on your webpages, and also the ability to track that DOM Content Loaded. So, immediately after that, you've got DOM interactive where users are actually able to scroll and interact with your application. Next, we've also got the Page rendering. So after the document object model's been rendered on your page you're going to have all of the assets that are loading after the DOM Content Loaded Event. And you'll also be able to look into the performance of those. So obviously these are two key events. So they are very useful to us. You know, we can take action when we see a deviation on the performance of these. You can find out obviously where you're spending the time on your applications based off these. They're industry standard, you know, Google Analytics provides these, New Relic provides these, all of our competitors provide these two types of events. And also, when you're actually looking at these, you'll actually be able to analyse where you're actually spending the time and what's deviated within your application. If you suddenly see an increase in your DOM process time, et cetera. So, let's actually have a look at the Performance and Navigation API actually in the real world. So I'm not actually going to dive into New Relic yet. I'm going to dive into New Relic and show you that at the end of this segment of slides. What I want to show you is, typically what we're seeing here. So, I happen to have a sample site here that we use at New Relic to demonstrate our software. And this our Acme Telco site. So what I did was I opened up the profiler, the developer tools. Unfortunately for Google, Alex has left unfortunately so I won't offend him with the ? Side of things. So what we're able to see in my tool is this fairly fast site. It's the DOM Content Loaded occurred at 759 milliseconds. The Page Load occurred at 1.87 seconds. And we actually look at the developer tools here. This is what that journey looked like. So, I can see, in this case, that my DOM Content Loaded occurred here. You can see that occurred around 759 milliseconds. And then we've got our Page Load Event occurring here around whatever it was, 1.87 seconds. Obviously, that's useful information, but what if we wanted to actually go further than this. So what we can actually do is we can look for events that may be more relevant to us. I don't know if you have maybe a business team that's behind your applications and your projects. They're asking you obviously for KPI's that you need to deliver for your applications or always on your backs trying to perform performance, et cetera. There's a lot of different metrics that we can actually get. Typically, obviously, there's the Page Load. Something we saw in the timeline back there was actually that the actual page had pretty much rendered before the DOM Content Loaded Event had actually fired. And we'd also seen that the Page Load, the content was pretty much there on the screen. So this comes back to really the event that we should really be going after is actually something called Perceived Load Time, not actually the Page Load Time, as a metric. So if we look at that time load here as well, what we can actually see if technically our perceived Load Time where our user actually believed that webpage was actually interactive or deliverable irrespective of it being actually interactive because after DOM interactive is fired then they'll be able to interact the page. We can actually see that this page is very fast in the rendering of this, and we're seeing it actually the content was being shown at this point. Also, when you're trying to come up with a Perceived Load Time metric to be able to get back to the business or those that are interested or just trying to improve your site. These are not a one size fits all for every single website. They're all problematic metrics. Before I jump into this, there is a metric that's synthetically people always go after. I get asked loads of time and it's the First Meaningful Paint Candidate. So I get to work customers all over the world, and I get to see certain accounts where this is relevant. Certain accounts where this is not relevant. Happens to be on this Telco site. First Meaningful Paint Candidate is not relevant, so it fired at this point, there's nothing on the page. It's not actually meaningful, so obviously, this will vary depending on different websites. And obviously, if you're working upon multiple websites. But, as I said before, these are problematic metrics, and there is no one way to do this. So what we can do in New Relic, is obviously out of the box you're going to get the DOM Content Loaded. You're going to get the DOM Processing Time you're going to get the Page Load, you're going to get loads of rich features that are available just in the standard product. But if we want to take this a step further, what we can actually do, is we can utilise the User Timing API. Alongside the New Relic Browser API to actually extend the performance to your site. So, the New Relic Browser API, if you head over to this site, docs.newrelic.com what you're going to be presented with is, obviously, all of our documentation for the vast variety of products that we have. But, specifically, if you choose Browser, and you'll be able to find our Browser agent here in SPA API. And this is going to basically provide you a whole host of different things you can do. So there is tonnes of use cases is what you can do with this. As an example, you can use a Page Action to send data into our Insights product which will allow you to query that. You might want to do that if you have an eCommerce application. You want to store the basket data into Insights to Query in a dashboard or do interesting things. Today, I'm only gonna focus, actually, on two items here. We're gonna look at adding to a trace and we're also gonna look at the set custom attribute value to basically augment the data that we have so what we have here is a sample application that a guy called Clay Smith, who's a developer advocate at New Relic, has generated and with this we're basically tying into that user timing API and what we have is a customised job script snippet here that gets appended to the existing snippet that is injected into the site. And, what we're doing here is that we're tying in and listening for the window DOT performance events to occur. And, with that, we're then calling out to our API points or API methods to augment the data that's being collected. So, in this case, we're confirming whether the browser that has that job script snippet in it actually supports the think functionality, otherwise, we'll just return with "not supported". And, in this case, we'll go and add and extend the trace here using this, we'll also start adding extra timing points. So, obviously, with this instrumentation that is fairly minimal, considering what we've got there, we can actually add on a whole load of features. So, given this is our site, what would be some interesting measurement points that we could go after? Well, firstly, we could look at perhaps this logo. Maybe we care about when this logo appears. We could look at the navigation items. Maybe that navigation bar, we'd want to know when that navigational bar appears. One key metric that I mentioned is Hero Images. This happens to be a very good indicator for when perceived load time is there for your users. We can tie in to get that metric. You could also be looking at Time to Text. So how long would it take this text to appear. Another metric, that's cut off slightly here, is DOM Interactive, fairly, quite simplistic metric to get. As I mentioned before, some of these metrics, they're not gonna be perfect for every single site. Sites are different, certain sites you'll have to have a customised approach and you'll want to analyse, obviously, what is the best approach for each site. So, Netflix actually used this as their measurement and, obviously, the idea here is test it first. We can look at key resources on the page. Whether they're being blocked by Java Scripts and so on, you could measure those. Another key metric that I see is, people are very interested in Above the Fold. One of the issues with Above the Fold is it's gotta be defined by a developer. Another one that Facebook uses also is Time to First Interact, so when did your users start clicking or scrolling, et cetera, in the application. Time for a plug. So, if you want to trial any of these features, or so on, or want access to these, you can head over to newrelic.com and you can download and utilise this product for two weeks free of charge and, obviously, gain full access to everything that we've been through today. And that concludes my short presentation.