Check out a free preview of the full Web Performance Fundamentals, v2 course
The "Measuring DOMContentLoaded & Load Events" Lesson is part of the full, Web Performance Fundamentals, v2 course featured in this preview video. Here's what you'd learn in this lesson:
Todd explains two legacy metrics used to measure web performance: DOM content loaded and the load event. DOM content loaded refers to when the HTML document has fully downloaded and any JavaScript in it has been executed, while the load event signifies when all known resources, including images, have been downloaded and rendered.
Transcript from the "Measuring DOMContentLoaded & Load Events" Lesson
[00:00:00]
>> Todd Gardner: So let's get into some legacy metrics. The first legacy metric is DOMContentLoaded. And I don't mean legacy like it's going away, I mean legacy in that we used to measure web performance using these things, and we largely don't anymore, but they're still important to know.
[00:00:24]
It means, specifically, that the HTML, that initial blue bar, has loaded, has fully downloaded. We've parsed it, we know everything in it, and any scripts, any JavaScript, that's in it has been fully executed. So everything in the document is done.
[00:00:38]
Now, images might not have loaded, but the HTML document itself is done. So here's an example, so this is that same waterfall chart from our example, and here's where DOMContentLoaded falls in place. So we downloaded the HTML, right away we needed to download some, some style sheets and we downloaded some JavaScripts.
[00:01:01]
As soon as that JavaScript is done, the last, which is the only JavaScript on the page DOMContentLoaded, has fired. Now there's still some images going on. There's, if we're visibly looking at this web page, those images are slowly drawing line by line to be displayed to the user, but DOMContentLoaded has now fired.
[00:01:20]
If we take a look at an example, here is a film strip of loading. And this is the old geocities.com website, because, again, I'm old and I've been doing web stuff for a very long time. So geocities.com, here's about where DOMContentLoaded would be. So the user starts navigating to the page and there's nothing there, then we things start drawing in, and presumably JavaScript is firing and various bits are being parsed and understood.
[00:01:49]
And then, before the images are all there, DOMContentLoaded has fired. Now then, other stuff happens, more images come down, more stuff gets rendered, other things happen, but the DOMContentLoaded event has fired. Why might we use this? This understands that the structure of the page is done. If you want to understand like every DOM element, every element in the page is addressable.
[00:02:16]
You can grab it, you can do stuff with it. The structure of the page is done, but images media might not be displayed yet. So, here's an example, here's how you would listen to this. This is just a common event that's thrown globally called DOMContentLoaded. We can grab it, just window add event listener, DOMContentLoaded, and print it out.
[00:02:37]
And it gives us an event with a timestamp on it. That timestamp is the milliseconds for that event, which in this case would be 1807 milliseconds for this particular website. You can throw this at source code, you could see when DOMContentLoaded is. The second legacy metric that's really important is just the load event, which is super generic word.
[00:03:02]
It's often confused because when a website loads and when the load event happens, isn't always felt like the same thing. The load event has a specific definition, and it's when the HTML and all known resources have been downloaded and rendered. So all of those images are down complete and on the page, that we know about.
[00:03:26]
Now, it's important to call out known because with JavaScript, we could add more images to the page dynamically. We could add content, we could do client side rendering, we could inject new things, those can happen at any time. If they happen before the load event, the load event will wait for them.
[00:03:42]
If they happened after the load event, obviously, the load event has already fired. Now the exception is if we just tell the browser explicitly to load something lazily, which we're gonna talk a lot about, those can go well past the load event. Let's put that in the waterfall.
[00:04:00]
So here is that same waterfall chart where, with DOMContentLoaded. Notice that the load event in red is all the way at the end of the last image. So everything that we knew about when the document starts loading is now complete and on the page. This is also the time when the little spinner in the browser stops, or the loading thing in the lower corner, depending on which browser you're using, has fired.
[00:04:25]
When the load event happens, that's typically when the browser does that sort of indication to the user that things are done. Whether or not it's actually done may not be true. So in the case of geocities.com, here's that load event right there at the end.
>> Todd Gardner: So the document is ready and updating and reporting tasks can begin.
[00:04:48]
So anything that we would do after the initial setup of the page, we can begin. How you would use this, I'm sure you've written this in JavaScript code many times, window add event listener load. Super often people will add this as like a wrapper of their JavaScript. They don't want their JavaScript to start executing until after everything is done.
[00:05:11]
That event, off a load also has a timestamp, which gives us the exact milliseconds of when it happens. So this might look super familiar from a non performance perspective, because there's lots of reasons why you would attach this things as part of the startup tasks of your application.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops