In the past few years, there has been a number of front end features in which the performance onus has shifted from browser to developer. Rather than the presumed “browsers will get faster at running my code”, there is a little more “I need to change the way I code for browsers to get faster.”
allows an author to inform the UA ahead of time of what kinds of changes they are likely to make to an element. This allows the UA to optimize how they handle the element ahead of time, performing potentially-expensive work preparing for an animation before the animation actually begins.
In other words, in addition to using animations and transforms, tell the browser what you are going to change within those animations and transforms.
The contain property allows an author to indicate that an element and its contents are, as much as possible, independent of the rest of the document tree. This allows user agents to utilize much stronger optimizations when rendering a page using contain properly, and allows authors to be confident that their page won’t accidentally fall into a slow code path due to an innocuous change.
In other words, if you know certain things about an element and its descendants, you should tell the browser so it can optimize around those things. For example…
contain: size; – “This ensures that the containing element can be laid out without needing to examine its descendants.”
Lol, check out this dog: images.example.com/jsK3jkl
I had a ham sandwich today. #goodtimes
I have political opinions that you need to hear!
Michael Scharnagl recently wrote a post on this:
Much like an iframe, this boundary establishes a new layout root, ensuring that DOM changes in the sub-tree never trigger reflows in the parent document.
Perhaps the most visible of these “you tell the browser what’s up” scenarios is responsive images, and particularly the sizes attribute.
The user agent will calculate the effective pixel density of each image from the specified w descriptors and the specified rendered size in the sizes attribute. It can then choose any of the given resources depending on the user’s screen’s pixel density, zoom level, and possibly other factors such as the user’s network conditions.
Here’s an example from the spec, where you’re giving the browser as much as you can to work with:
sizes="(max-width: 30em) 100vw, (max-width: 50em) 50vw, calc(33vw - 100px)"
srcset="swing-200.jpg 200w, swing-400.jpg 400w, swing-800.jpg 800w, swing-1600.jpg 1600w"
- If the browser window is narrower than
30em, I’ll be displaying the image at
- If the browser window is between
50em, I’ll be displaying the image at
- Otherwise (if it’s even bigger), I’ll be displaying the image at
calc(33vw - 100px)wide.
Which then needs to match up with what you actually do in the CSS. Hopefully it’s fairly accurate, so the browser optimizations match up with reality.
A Brave New World
I mention these things not because I think you need to run out and start using all this immediately. More to spotlight the (if I may) trend, in front end performance-related features in which the browsers ask more of authors.
I think the browser vendors and spec authors would say: “You want performance. There is only so much we can do. There are certain things we can’t know, but you do know. We’ll do our best without them, but if you tell us about them we can do much more.”
What say you?