Rachel: Before we dive too far into the tools which are fun, it's important that we acknowledge, that all browsers have slightly different rendering pipelines. They all have their own ways of doing things and a lot of perf people, tend to forget that and only optimize for Chrome. Because it's got the nicest dev tools and it's got the biggest share of the market, but Chrome is not the only browser.
And it has a very specific performance space and it has a very specific pipeline for rendering things. But it is one that we are very familiar with, and thus I will use it to describe one browser's kind of development. This is CSS.
Speaker 2: Sorry I'm going to interrupt, can we just get that question really quick?
Rachel: Yes, I'm sorry.
Speaker 2: There's, no, that's okay. Okay, so before you jump into performance staff, Christine has a question, is there any way to reverse an animation from animation fill, forwards back to the beginning, initiated by user action?
Rachel: That's a good question. Let's see, reverse an animation from fill forwards.
Rachel: I would assume that Christine has already tried using something like changing the animation to reverse in that situation, changing its direction to reverse. But you would need to also give it another set of iterations to complete. And you would have to trigger it to play. So to that, I'm going to answer I don't know.
I haven't encountered that use case myself, so I don't know how to provide a solution for it. If anyone has any ideas, would be awesome to share them with Christine.
Speaker 3: GreenSock.
Rachel: What did you say?
Speaker 3: GreenSock.
Speaker 3: GSAP.
Rachel: All right, that's one option but GreenSock is not CSS animation.
All right, so this is csstriggers.com. It used to just be for Chrome. This is maintained by some Chrome folks. So originally, it was just for the Blink engine. But now it displays information, about Blink, Gecko, that is, I believe, Firefox, WebKit, Safari, Opera. Sorry, Opera is blank and edgeHTML.
So now we can see how all of these different CSS properties affect their rendering pipelines as well. So change from default is that initial change, when you first animate something and then subsequent updates after it started changing, how much does it cost to continue changing it. I'm going to assume that the blank spots here are for information insufficient.
Now as you can see these do change a little bit, from one to the other. This is color coded so the purple bars represent layout, the light green ones represent paint and the dark green ones represent composite. What do those mean? So does anyone remember when we used to build websites?
We were admonished not to use percentages. We used to use tables, and you could set them to be like 50% wide, and the cell would be 25% wide. And all of the books used to say things like, don't use percentages on your images or on your layouts because browsers take a long time to calculate those, use exact widths.
So then we started being like, okay, exact width, okay, it's 800 pixels wide and the image should be this. Browsers are a lot better at doing that. Computers are a lot faster and now we can use percentages like nobody's business. But it still takes browsers time to calculate, where everything should be on the page.
From its width all the way to how long the text is, where this image appears, etc. It does all these calculations, that's called the layout process, where it's calculating where things go. The paint process is where the individual items are painted, sometimes on the GPU. They are painted and then composite happens.
Where those things are pasted into the layout. That's might be a pidgin way of putting it, but that's the best way I can describe, it's a three-step process. The where, the what, and then combining them. So, we can see which of these different effects are being triggered by which of these different CSS properties.
I get to do this one all on the screen now. So when we see solid bars, that's a very bad sign. For instance, a line items. That changes if words are centered or if they're right or left aligned. This can change layout in pretty big ways. So not only does it trigger layout, but it also triggers repaints, and it triggers composites.
So it's a very intensive thing for any browser to perform. We get to backface-visibility, we start seeing that in different browsers, it doesn't trigger layouts. It doesn't trigger in Firefox, it appears to not trigger paint either. So once you start seeing these bars greying out, these are things that are better to animate.
I don't believe that you can animate background-attachment, by the way. Sometimes, that's why they are grayed out. All right, like background-repeat, that's not animatable. So let's see. Let's go on this little stroll. Borders trigger all kinds of stuff because when you change something's width, you're pushing things around on the page.
No, I gotta go do the layout. It's a really expensive performance problem. Cursor, cursor's great, not that you can animate that. So many solid bars, what can we orphans, orphans? Man. Perspective, this is a 3D transform property, which we haven't been using at all today. Things associated with 3D transforms tend to be very performant.
Here we go, transform. So transform as you can see on blink, that is to say on Chrome and the new Opera. Transform is very performant in that it does not trigger layouts and it does not trigger repaints. So when you're moving something around, using transform it's not actually re-positioning anything else on the page.
So Chrome just kicks it over to the GPU. And continues onward with its currently out and doesn't bother re-calculating anything. But you can see that in the other browsers, that's not the case. So, this might not be as performant on other browsers as it is here in Chrome.
Although it looks like Edge at least doesn't trigger layouts after that initial change. That's nice to know Edge, thank you. And opacity should be in here too. I was a bit surprised by opacity but it is a little bit more across the board performant than transform. These are our two favorites as far as animatable properties, these are our two favorites to win, opacity and transform.
Because they're the least disruptive across the most browsers. You can see here that opacity in Blink, in Firefox, and even in Edge, does not trigger layouts. And in Chrome, in Blink, it doesn't trigger repaints either on subsequent changes. So it's a handy resource. But once again, you should definitely try to check these against the browsers you're developing for.
Because sometimes, things don't perform the way you think they would. So our two best friends are opacity and transform because they trigger the least amount of layouts, the least amount of repaints. So how do we take common animations and think of them in terms of transform and opacity?
As a designer, this is really, really, really, really important, because I have seen designers do some really cool things. Then try to hand them off to developers and the developer be like, this does not look good in the browser at all. You can't do all of these things.
In fact I have actually made some things that today don't perform too well. We'll look at some of those too. Once again, I use my own examples, because if I'm going to embarrass anyone, I should embarrass myself. But first, let's take a look at some of these things that we can convert over.
For instance, instead of animating height or width, which trigger a lot of layout. You can use scale to transform the size of something or something's container. Instead of transforming position, like using position absolute top zero, left zero and then animating the top and left properties. You can use translate.
Translate is going to position that element in relation to where it existed previously. It's sort of like position relative, except it doesn't move anything else around it.
Rachel: And we can use opacity instead of using z-index or visibility hidden. Just a really quick opacity change can look like a jump cut.
And sometimes you want that.