Check out a free preview of the full CSS Animations and Transitions course

The "What to Animate" Lesson is part of the full, CSS Animations and Transitions course featured in this preview video. Here's what you'd learn in this lesson:

David discusses performance considerations when animating CSS properties. Properties like transform and opacity are less expensive to animate because they don't require recalculation of the layout or a repaint. Other properties like height and width require a repaint and negatively impact the performance of the page.


Transcript from the "What to Animate" Lesson

>> The last thing I wanna talk about in terms of fundamentals is what to animate. So with CSS, you could actually animate a lot of things. So, for example, let's say that I wanted to animate the font size of this h1. So let's say that this is font size, probably 2rem or something like that.

Let's say I wanted to make it really big. And so when I hover over it, and this is a good SAS lesson, too, if you put the ampersand, it's going to basically copy this over and put that over here. So if I do hover and I do font-size, something big, like 5vw or something like that.

That's not very big, [LAUGH] let's do it like 10vw, just so you could see that it is going from small to bigger. And again, if you don't want to use SCSS, this is exactly the same as doing this. So, When you hover over it, the font size is going to be big.

Now, let's add a transition. And so again, this is just an example, we're gonna be talking about this in the next lesson. But, When I hover over it, the font size does get a little bit bigger. Now, the problem with this, which it might not seem like a problem, but it definitely does become a problem when you had a web app or a complex website that has a ton of different elements and those elements are all nested in each other and everything like that.

The problem is that these kinds of animations actually become expensive. And so by expensive, I mean they trigger what's called layouts. And so you could look at more information on But the main idea is that when you're animating, there's two different things that are doing the animation in CSS.

There is the GPU, which is the graphics processing unit, and the CPU, which is the, I just say CPU, computer processing unit, something like that. And so the GPU, when you hand things off to the GPU, you're basically giving it a surface in which it could do a lot of things in a really fast way, which is to transform it and to change the opacity.

Because think about having it on a really stretchy piece of paper. With that paper, you don't care about any other elements on the website. You could stretch it, you can make it longer, you could shrink it, you could skew it, you could rotate it, you could do all sorts of things with it.

You could even animate it in 3D. And so what's performance about this and what the GPU is really good at is because it's on its own layer, we don't need to care about the other elements. So we don't need to do the computation of if this moves, then these other elements should move.

So again, the GPU is really good at that. And these are going to be where your most performant animations are. And by performance I mean getting to 60 frames per second or as close to 60 frames per second as possible. Now when we do color in background, now we're not talking to the GPU.

We're talking to the browser, or, well, I mean, we're always talking to the browser but we're more talking to the CPU. Because it needs to actually change the color of something or change the background, just replace it with something else and calculate the transitions between, for example, two different colors.

Now, while this is not going to trigger layout and it's not going to say, cuz when you change the color of something, you're not moving anything. So we're not having to do any of those computations, instead we're just changing the color, that triggers paint. And so triggering paints, you could still get to 60 frames per second, but if you're triggering paints on a lot of elements, that could actually be computationally expensive.

So whereas transforms and opacity are really performance, color and background is something that of course, you can animate them, but you want to be really careful about animating them. Now the things where you want to avoid animating as much as possible, are things that trigger layout. And so these are things like height, width, left, right, margin, padding, even border sizes.

Those things are going to trigger layout and be the most computationally expensive for the CPU to animate. And the reason is because when you are changing one of these properties, the browser has to reflow all the elements that are surrounding it, and maybe even more elements like the parents.

And so now you're not just animating one thing. You also have to think about how everything else is positioned in the browser. So it's sort of like a domino effect where if you change the margin on one elements that affects another elements, which could affect the parents, which could affect its neighboring elements, which could affect their parents, and it just becomes a mess.

So we're gonna be talking about that too, we're basically only going to be using transform opacity, and color, and background. So again, try to avoid animating height, width, left, and right. Now the last thing I wanna say about this is I talked about 60 frames per second as a goal.

And so 60 frames per second seems like a really arbitrary number. And some of you might be saying, hey, I have games that play at 30 frames per second and they're pretty snappy, or I have a VR headset that's 100 frames per second. So what is so special about 60 frames per second?

And so what's special about is that, that is the monitor refresh rate. So the monitor is refreshing every, it comes out to 16.667 milliseconds, and so that is your window where it's basically a frame of an animation. So if you remember those old films, those big film strips, you could think of every 16.667 milliseconds as one panel of those film strips.

So what happens if you miss that window because something is taking too long to animate, or to compute for the animation, is that it's going to exceed that budget of 16.67 milliseconds and bleed over into the next animation frame. And now you're going to have multiple animation frames with the same animation.

And so the result to the user is what's called jank, where it doesn't feel smooth, it feels like it's stopping. And then it's going back to where it needs to be and then stopping, and it just feels very laggy. It's not a very pleasant user experience. So that is all the fundamentals I wanted to talk about.

Are there any questions?
>> You got more of a comment, I guess. But-
>> Yeah.
>> I'm glad you bring this up because I think with a lot of animations, you don't really think about the end performance, you try and make it cool. And that's taxing on the page.

And with things coming up like Google performance, your Lighthouse score goes way down with your repaints and your reshifts, and then your page drops down in that SEO listing. Which is not something that every developer thinks about when they're making a feature or animating something. So I'm glad you bring that up because it's not always on the forefront of every developer in my experience,

>> Right, yeah, that's a really good point, especially if you want your website to get all of those green rings for Lighthouse insights, where, You could generate a report, I actually don't know how well this is going to perform. But, [LAUGH] it does become a factor, where if you're doing a lot of layout animations and things like that, then it is going to affect your score.

So you see here we have a 99 performance and other things. SEO, I don't care about because we're on local host we don't really want anyone to discover this. But yeah, that is an important factor, yes.
>> What if you would use transform to scale size?
>> So again, using transform, it's going to be on the GPU, not the CPU, and so it's actually going to be really performant.

And so by scaling size, there's two different things you could do, you could scale the x which is how wide it is, and you could scale the y which is how tall it is. And so, again, with that metaphor of considering your elements on a piece of paper that's really stretchy.

That's really performant, because you're not affecting any other elements. So just think of a stretchy paper. You can move it this way, this way, rotate it, do whatever you want with it.

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