A Guide to Animation Performance on the Web

2.3 How Browsers Work Behind the Scenes

In lesson one we had a quick look at what a browser is doing after you type in an address and hit Enter. Now because this course is not about DNS lookups and HTTP requests, let's actually have a look at how a browser renders a web page. There is a series of steps a browser goes through when rendering a page. And it looks something like this, so starting from the top we have styles. This basically matches elements with CSS selectors, and calculates which styles should be applied. Then we have layout, this handles the dimensions and position of elements and is triggered by properties like width, height, margin, padding, top left and so on. On the next position is paint. Now paint is responsible for filling in all visible pixels. And it's triggered by properties like color, background color, border styles, shadows, and so on. This is by far the most expensive operation in terms of resources. And finally we have composite. This will take everything that's generated by paint, order it and output it to the screen. This basically shows you the final web page and it's also triggered by the transform, opacity, and filter properties, remember the animation friendly properties. Now this looks and works like a cascade, if something happens on the top, all the layers below will get triggered. For example, if you change a color, that triggers paint and paint, in turn, triggers composite. If you trigger layout, that triggers paint and then composite. If you're looking for more information on what triggers what, check out www.csstriggers.com, it's a great resource for learning what each property is triggering in terms of the rendering waterfall. So now that we know how a browser renders a webpage, maybe it's easier to understand why using the animation friendly properties like transform and opacity is recommended for animations. It's simple. These properties trigger the composite step, which is the last one in the waterfall. So usually nothing else gets triggered, and the browser doesn't have to recalculate a lot of things. Now before we wrap up this short lesson, I want to quickly talk about the two threads the browser uses to execute tasks. As you can see from this graphic, the two threads are main and the compositor. The main thread uses the CPU exclusively. And it handles JavaScript, Styles, Layout and Paint. This is basically where all the heavy lifting is done by the browser. The compositor thread uses the CPU but also the GPU and it handles the composite step. This is basically where hardware acceleration happens. In simpler terms if we have a task that doesn't trigger the main thread, like for example, a transform, the browser can then create a new compositor layer. This layer is then uploaded to and rendered by the GPU. So, to sum it up. In order to create high performance animations, fluid animations, you need to avoid using properties that will trigger either the main thread or the very top level of the waterfall. Also take advantage of hardware acceleration and properties that will trigger the compositor thread. Alright, now, let's move on to how to measure animation performance, right? Because we've had all this talk about performance. But how do you measure that? Are there tools? Well, there are and we'll talk more about those tools in the next lesson.