Advanced Web Development Quiz

Q7: PerformanceNavigationTiming

Lydia Hallie

Lydia Hallie

Lydia Hallie
Advanced Web Development Quiz

Check out a free preview of the full Advanced Web Development Quiz course

The "Q7: PerformanceNavigationTiming" Lesson is part of the full, Advanced Web Development Quiz course featured in this preview video. Here's what you'd learn in this lesson:

Students are instructed to put the PerformanceNavigationTimings in the correct order. The properties include loadEventStart, domComplete, domContentLoadedEventStart, fetchStart, connectEnd, and domInteractive.


Transcript from the "Q7: PerformanceNavigationTiming" Lesson

>> Put the PerformanceNavigationTimings in the right order. So we have loadEventStart, domComplete, domContentLoadedEventStart, [LAUGH] fetchStart, connectEnd, and domInteractive. All right, let's see the answers. So first, we have fetchStart, then connectEnd, domInteractive, domContentLoadedEventStart, domComplete, and at the very end, we have loadEventStart. So, we can use the PerformanceNavigationTiming API to get detailed timing information about various phases of the page navigation.

For example, first, we have the entire DNS lookup again. We can use a domain lookup start to get the timing right before it starts a DNS lookup, and then domain lookup end to get the timing right after it finished. So this we can check, all right, is our DNS right?

Do I maybe have to change something in my DNS servers? Is that all good? Next, we have TCP, right, establishing that connection to which we have the connectStart. And if it uses HTTPS, you can also get the secure connectionStart to get that TLS connectionStart. And of course, the connectEnd, when that's all ready.

It's all connected to your server. Next, we actually have the HTTP request. So requestStart is when it sends a request to the server. And at the very end, we have the responseStart. So when the very first byte of the response comes, and then responseEnd. So comparing responseStart and responseEnd can kinda say, all right, is our response coming through, right?

Do we need to optimize anything there? So next, we have domLoading, which is the time at which the browser starts to actually process the the HTML. So it kind of returns to time when the browser sets the document ready state to loading. Also, just FYI, domLoading can happen before responseEnd, because browsers are able to kind of parse the response stream as it gets in.

So it's not entirely fair to kinda put it in a timeline like this happens first, this happens after. In many cases, the domLoading can happen before responseEnd, because it can kind of start processing the stream as it gets in. But next, we have domInteractive, which represents a time at which the DOM structure is complete and the HTML document has been parsed, but there might still be some resources that haven't been loaded yet.

This is just the time that it took to construct the DOM between domLoading and domInteractive. So then we have the domContentLoadedEventStart, which is the time right before the browser fires the domContentLoadedEvent. And in many cases, you may have some event listeners listening to that, and this is also when, for example, the different scripts and everything load async scripts, all that stuff.

And then we, of course, at domContentLoadedEventEnd. So comparing domContentLoadedEventStart, it's such a long word, with the End, you can kind of see how long it takes to process and execute all the event handlers listening to that event. And then finally, we have the domComplete, which returns a time right after the browser sets the ready state to ready.

So in this case, the DOM is completely loaded. The resources are now also fully loaded, all the deferred scripts, all of that is ready, any images, nothing is still loading. And then finally, we have the loadEventStart. I can't really visualize that, but that is like event listeners listening to the load events.

And then, we have the loadEventEnd, which specifies the time when all these listeners have finished executing. Sometimes, some, I don't know, if you've worked with frameworks or any other tool, you may have seen like the at event listener load ,then do this. Just to make sure that if we wanna do something, the entire DOM is constructed, all the resources are already there, people can see stuff on the screen, and so on.

So this is the PerformanceNavigationTiming API, and this is provided to you. You can use it if you just wanna kind of see how well your website is doing. Yeah, you can see all those timings. There's a new one now, there's V2. For a long time, they used V1, so just make sure that you're not using an outdated one, cuz they have slightly different values.

I also kinda skipped the entire caching here, cuz of course, every resource is cached. It doesn't have to have the entire HTTP request, all that stuff, but this is kind of the most basic timeline of that timing event.

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