Web App Performance

Performance & Navigation Timing APIs

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
Web App Performance

Check out a free preview of the full Web App Performance course

The "Performance & Navigation Timing APIs" Lesson is part of the full, Web App Performance course featured in this preview video. Here's what you'd learn in this lesson:

Max introduces the Performance & Navigation Timing API. The properties and methods in this API give developers precise details about a page's performance and the metrics can be used for creating robust custom reports.


Transcript from the "Performance & Navigation Timing APIs" Lesson

>> So far, we've seen how to apply web performance. We create a website, right, then you are attending this workshop, you are watching this course, and then you learn to measure things, you apply some techniques that we have been seeing to see if that, I mean, preload, DNS prefetch, 14K.

And then, you go back, make changes, measure, okay, that's kind of one thing, which is okay. We do that in the lab, okay? We iterate over this many times until you go and deploy. When you deploy, that goes to the user. It shouldn't, I mean, web performance optimization shouldn't stop with the deployment.

You should also measure real user metrics and do two things, make decisions on the fly for that user, that's why I mentioned reactive web performance. So for example, if the latency is too high, well, let's decrease the amount of data or let's make only one request and try to bring many things at once.

And also, with those measurements, we can go back to apply techniques. We can gather real user metrics and make new decisions that will make changes to the code as well. So that's how your performance process should look like. So it's not just static performance, also dynamic performance on the fly, okay?

The APIs, as we will see, work client-side. Some data that you get there can be share with the server automatically or manually, and as every API in the web world is not available, some APIs will not be available in every browser, okay? So sometimes, we have polyfills, that's a library that will simulate, will fill the gap that we have on some browsers, and for that, we can measure timings.

What is timing? Remember the waterfall chart? We could recreate the waterfall chart in a JavaScript structure. So all the information you see in the waterfall chart can be accessed by JavaScript, by a JavaScript API. For what? For what you need. You can read type of connection, bandwidth latency, device memory, and you can create your own custom metrics with these APIs.

You can read paint timings such as first-contentful-paint, large-contentful-paint, and CPU-intense operations such as, remember that I mentioned long tasks, these tasks that are taking more than 50 milliseconds, you can get warned every time you're going over that line. So then, you can gather real user metrics for that user, for that CPU, for that device, we might have a long task problem.

So that's known as real user monitoring or RUM, because we don't know how users are working with our site, just working with our lab, okay? So it's a good idea to take analytics. Of course, there are a lot of providers out there, companies, where you inject the code and they will do that for you.

They have nice dashboards, alerts, but also, you can do it yourself, and I will just give you a hint of some ideas that you can use for the APIs. There are many APIs, we are not going to cover all the APIs. We can do a full workshop on performance APIs, it's just an idea to get you up and running with the basics, okay?

Let's say that the base of everything that we will mention in this section is under the performance option, have you ever seen that one? It's a global object available in the context. So if I open any website, it can be my website, let's go back to Frontend Museum, let me close everything.

If I go to the console, we can try the performance object. So that object is actually like the root of most of the performance APIs. For example, there we have a navigation option. On that navigation, we can know which type of navigation do we have. One is actually a normal navigation, so I just type the URL.

I can also have a BFCache navigation, so it means the current navigation, the user is going back, or the user went back to our website, remember BFCache. And also, I can see the redirect count, so to get to this navigation, how many redirects were necessary? So over here also, there is a performance.now function that will give you the current time.

But you say, the current time expressed in which unit, which kind of weird, right? If I refresh this, [COUGH] and get performance.now(), it's actually a small number. It's expressed in milliseconds since the zero of the timeline, since I have started the navigation. And you can use this to measure things on your page, to see how much time has passed since, performance on that will give you, and also it's high precision.

Technically, the precision goes to the nanoseconds. But yeah, it's a theory, right, not the reality. So it's milliseconds, okay, it's much better than doing this, new Date().getTime(), why? Because this is, first, the amount of milliseconds since 1st of January, 1970. The precision is milliseconds only. And also, you're creating an object in memory, new date, looking for memory, so you're actually changing the observation.

That's not a good idea. performance.now(), you can see it's faster, it's actually native, and it's accessing like a high precision timer. So on this performance object, we have everything you need for the performance APIs. So we have already seen this, so how to get the current timestamp, we have already seen that.

By the way, the timeOrigin will give you the timestamp for the zero, if you need to convert that into a normal date. Also, you can get the redirectCount. I already said that, and this is the kind of kind of navigation you have, it's a normal navigation, it's a reload or it's a back_forward.

And level 2, level 2 means the version 2 of the API. We do have a lot of timestamps, a lot. So actually, what you see there is all the steps of loading a web page. And actually, you have lot of places there where you can get the timestamp, navigationStart, fetchStart.

When the SSL connection started, it's called connectEnd. When the HTTP request started, that's requestStart. When the CSS and JavaScript parsing started, that's domInteractive, and so on. And you can read the timestamp, so you can actually design, if you want, on the screen using Canvas, for example, you can actually design a waterfall chart just by gathering the information from this API.

And again, with this, you can make some decisions, for example. So if you wanna, for example, calculate time to first byte, you get responseStart minus fetchStart, that's time to first byte. Anyway, time to first byte is kind of at the backend time. If you want download time, so the downloading of the HTML, responseEnd minus responseStart.

You want DOM load time, domInteractive minus, parsing and rendering time, and you use that for your own purposes. Does it make sense? That's kind of the idea. And page load time that no one cares anymore, okay, is domComplete minus fetchStart.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now