Web App Performance

Resource Loading, Frames, & Interactivity

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
Web App Performance

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

The "Resource Loading, Frames, & Interactivity" 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 cautions about using too many render-blocking resources, which must be loaded before the page content appears and is interactive. The implications of long-executing JavaScript and animations are also discussed in this lesson.


Transcript from the "Resource Loading, Frames, & Interactivity" Lesson

>> Two other things before actually starting to analyze how to improve performance now that we understand roughly how everything works. Typically, let's simplify a website a lot. We have HTML, we have JavaScript, and we have CSS, okay? That's the minimum. What I'm not sure if you know is that CSS, let's start with JavaScript.

JavaScript blocks parsing by default, which means the browser is reading the HTML. If the browser encounters a JavaScript, it will stop parsing, so it will not read the rest of the HTML. Let me show you this in action. In our Frontend Museum, example, when you look at the HTML, parsing is about reading, let's say, line by line and analyzing the code, understanding the elements, and creating the DOM, the document object model.

Well, here, for example, on line four, it gets into a script error. Well, because there isn't a script there, it will block the parsing. So it's not going to read the meta or the rest of the HTML until that JavaScript file is downloaded and executed, which is pretty bad for performance.

In the network layer, Let me refresh so we can get the full waterfall. Let me get off of the screenshot so we have more space, like so. We could see at some point, I'm not sure if it's easy to see here, but maybe here, that logo.png file didn't start the download process, Before the script finishes downloading.

Can you see that? So that's typically a case of, A problem like this. For example, if I open my index.html and I have more scripts like so, I can even add the hack like this, you will see how performance gets worse and worse, because it will wait for this one.

It's not going to download more files in parallel, it will go in sequence, one by one. That was ten years ago, there was best practice in web development that was saying, move all your script to the end. Have you seen that? That is both because let's defer that to the end so we don't block the rendering, okay?

Anyway, we'll get into that in a second. So JavaScript blocks parsing and rendering goes after parsing. So if we are blocking parsing, we're also blocking rendering, we are pushing rendering. CSS blocks rendering, which means the browser will never run the pixel on the screen if all the CSS that is known at that moment was not downloaded and parsed.

Even CSS that is not going to be applied right now, or even if the CSS it has a media query and the media query is currently false, it's going to download everything. It's going to parse the CSS, and only at that moment it will start rendering things on the screen.

And we know that most of the core web has to do with rendering, with seeing things on the screen. Well, and the last thing is frames and interactivity. That is just showing you this particular slide diagram that has to do with animation. So after the page was loaded, the browser has an animation loop, even if nothing moves on the page, there is an animation loop.

When you scroll with your finger, with your phone, you scroll, that's an animation loop going on. So there is always an animation. And the animation renders a frame, and then it analyzes input events. Input events is, have you scrolled, have you clicked, is your mouse over something? So every event that you have in JavaScript can be an input event.

After parsing those events, and that's actually your code, your JavaScript code. When your JavaScript code releases the thread, then the browser parses the HTML, styles, and layout in case you have changed something or in case you have moved the page and there is something else that needs to be analyzed.

Then it goes into paints and composite, and maybe there is an idle time before the next frame. And it's doing that, for example, 60 times per second, Okay, that's the idea. [INAUDIBLE] what happens if your JavaScript code is taking a second to execute? We have a problem because we are pushing the rest because it's only one thread.

So that means the animation will be bad, you won't get 60 frames per seconds, and you get into performance penalties, okay? So this is just, again, just how the browser works.

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