JavaScript Performance

JavaScript and the Render Pipeline

Steve Kinney

Steve Kinney

JavaScript Performance

Check out a free preview of the full JavaScript Performance course

The "JavaScript and the Render Pipeline" Lesson is part of the full, JavaScript Performance course featured in this preview video. Here's what you'd learn in this lesson:

JavaScript can change the look and behavior of a web page after it has been loaded. Depending on how it is used, it can trigger some or all of the steps taken to create the web page in the first place.


Transcript from the "JavaScript and the Render Pipeline" Lesson

>> Steve Kinney: Except.
>> Steve Kinney: That gets you to the very first page render, then our friend comes along and changes stuff, right. That'll get you to a static page, if you're a content site that will get you most of the way there, right. Again, see the lazy approach to web performance, new title for the course.

So likely that is not the only time that you are going to end up rendering the page, right. And most user interfaced based applications you're moving stuff around a lot, right. This is the large majority of what is happening there. And if you are doing weird stuff with objects and managing state the end result is you wanna display a UI, right.

You want to change the UI based on all of this other JavaScript calculation that you're doing. So an incomplete list of things that JavaScript can do that impact rendering performance is they can change the class of an object. What does that mean, does the class two x size, right, it, does it change the dimensions of it, does it change the color?

We don't know what that does so it means we need to do some part of the rendering process all over again. Did we change the inline styles of the objects is effectively the same as the changing the class, except darker. And adding or removing elements to the page, you might need to re-lay out the page, right.

These are all things that can happen. And for all the steps we saw before, okay, the DOM, the CSS object model, the render tree, right. We effectively mostly keep around the DOM and sometimes the CSS object model. If you change style sheets that's gotta be recalculated. But everything else that render tree needs to be remade.

When the render tree needs to be remade we probably need to re-layout the page. When layout changes we probably need to repaint the page, right. So anytime we have these big effects we end up having to redo a lot of this work. So it's not a one-time thing, it's a many times thing.

And there are some things you can do that really get you that. Remember that red bar along the top when we were in the introduction and we could say you could peg the CPU? You can do a lot of stuff in this process because they're all sharing the main thread, right.

Your painting, your layout, your JavaScript are all competing for the same computer resources, right. So kinda keeping those all together is important. So this is the render pipeline. Javascript can change the styles of a page by either adding or removing classes, which could change the geometry and the layout of the page.

That could change the colors. Like, okay, when they hover I wanna change this button from white to blue, right. That's gonna need you to repaint and then you need to send all that new data over to the GPU to get done, right, cool. So each one of those steps triggers everything change the style, change the computed styles all that recalculation has to happen.

Anything could change that may or may not have changed the geometry those things are now different, send it to GPU, cool. You don't always need to do all of those every time, right. In the event that you're just changing the background color or the opacity of an object, right.

Do you need to re-lay out the page? Probably not, right. So there are some times, especially with stuff like opacity and CSS transforms, where you can actually skip even the paint process. You can skip different parts of this. If the window resizes, none of the styles have changed so you can theoretically keep the style calculations, right.

It's just maybe the flexbox has different rules you might need to re-layout or re-paint. So you don't always need to do all of them, right. Sometimes you can skip a few of them, right. And that's what this whole section is about, right. Because not doing stuff, skipping entire sections will always be faster than doing them, right.

And the same corollary applies, right, of not doing stuff is faster than doing stuff, doing stuff more than you need to can also be problematic, right. So we want to skip whatever we can skip and we definitely don't wanna do anything more than we need to, right. Again, see the lazy approach to web performance, new title for the course.

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