Web Runtime Performance

Luis Vieira
Nov 1, 2016 · 6 min read

Many of todays performance concerns focus on getting assets to the user as fast as possible, page load time and time to first byte are often the most important and audited metrics, but runtime performance is many times forgotten and as important as these metrics.

It’s no good to have a optimized critical rendering path and a 1s time to first render, if then we provide an experience where scrolling feels slow and animations stutter, your website will still be perceived as slow and engagement will suffer.

Scrolling performance is crucial for content discovery, and fluid animations critical for a smooth experience and a good perception of speed.

Good principles for smooth animations

In order to make smooth 60fps animations you have to avoid making the browser go through all of the render pipeline each time you animate something.

Image for post
Image for post
Frame Render Pipeline from https://developers.google.com/web/fundamentals/performance/rendering/simplify-paint-complexity-and-reduce-paint-areas

When we’re animating we want the browser to do as less work as possible, properties like ‘width’ and ‘height’ trigger layout, so this means that anytime you animate this property the browser has to recalculate the full layout of the page, this means each element position and size.

Also when we animate properties such as color or visibility, we’re triggering a paint this means that the browser has to re-render all the affected elements and the layers they belong to.

Animating in the compositor layer

In order to achieve 60fps smoothness in our animations we need to animate properties that can animate in the compositor layer

Image for post
Image for post
This is the render pipeline we want to achieve skipping layout and paint and animating directly in the compositor layer from https://developers.google.com/web/fundamentals/performance/rendering/simplify-paint-complexity-and-reduce-paint-areas

Compositor layer

By default the browser paints elements to a single layer in memory, you can think of it as a photoshop layer where all elements are placed there. In order to animate in a independent single layer while skipping layout and paint, we need to promote elements to their own layers.

element{
will-change: transform;
}
//or for older browsers
element{
transform: translateZ(0);
}

These rules will instruct the browser to promote the targeted element to it’s own compositor layer. Use this sparingly, layers consume memory and using them excessively may have unexpected results.

What can we animate then?
Not all css properties can be animated using the compositor layer, if you want to make high performance animations you’ll need to stick to these rules.

transform:translate()
transform:scale()
transform:rotate()
opacity

About Scroll

Scrolling is one of the most critical and common interactions in any website or application, that’s why it’s so critical that it remains smooth and jank free.

Everything starts with the DOM tree, which is essentially all the elements within the page. The browser takes a look at your styled DOM and it finds things that it thinks will look the same when you scroll. It then groups these elements together and takes a picture of them, which is called a layer. Each of these layers needs to be painted and rasterized to a texture and then composited together to the image that you see on screen.

A common function attached to scroll events is checking for elements in the page and the applying some css classes to them, this is a common pattern on parallax scrolling pages.

As scroll events fire at an high rate, as you check the position of each element in the DOM you’ll trigger a reflow, then as you atach css classes to those elements you’ll trigger a repaint.

A repaint occurs when changes are made to an elements skin that changes visibility, but do not affect its layout.

Examples of this include outline, visibility, or background color. According to Opera, repaint is expensive because the browser must verify the visibility of all other nodes in the DOM tree.

A reflow is even more critical to performance because it involves changes that affect the layout of a portion of the page (or the whole page).

/****
nasty scroll event function
***/
function onScroll() {
/****
Check for each element position in DOM
Check if element is in viewport
If true attach css class to element
*/
for(var i = 0; i < domElements.length; i++) {
//Check for each element position in DOM
var rect = domElements[i].getBoundingClientRect();
//Check if element is in viewport
if( rect.top >= 0 && rect.bottom <= window.innerHeight ){
//If true attach css class to element
domElements[i].classList.add('visible');
}
}
}
window.addEventListener('scroll', onScroll, false);

In the function above you can see that each time the scroll event fires we’re checking the position of a number of elements present in the DOM, and then making visual changes to those elements, triggering a reflow and repint each time. As the scroll event fires rapidly this will have a negative impact on sroll performance specially on less powerful devices.

This codepen is interesting to see the amount of times the scroll event fires and the amount of work we’re forcing the browser to do.

If you need to make any type of visual changes on scroll such as in a parallax website, it’s a good practice to do them on the next ‘requestAnimationFrame’.

var last_known_scroll_position = 0;
var ticking = false;

function doSomething(scroll_pos) {
// do something with the scroll position
}

window.addEventListener('scroll', function(e) {
last_known_scroll_position = window.scrollY;
if (!ticking) {
window.requestAnimationFrame(function() {
doSomething(last_known_scroll_position);
ticking = false;
});
}
ticking = true;
});

‘requestAnimationFrame’ is a new method available in the web platform that passes the responsibility of scheduling the animation to the browser, ensuring that the browser runs the animation before the next repaint making it easier to stay smooth at 60fps.

If you need to do non esssential work such as sending analytics data, processing information that isn’t immediately needed by the user, or that doesn’t require immediate visual feedback, you can wait until the browser is idle, do this in a ‘requestIdleCallback’.

After input processing, rendering and compositing for a given frame has been completed, the user agent’s main thread often becomes idle until either: the next frame begins; another pending task becomes eligible to run; or user input is received. This specification provides a means to schedule execution of callbacks during this otherwise idle time via a `requestIdleCallback`

requestIdleCallback(myNonEssentialWork);function myNonEssentialWork (deadline) {
while (deadline.timeRemaining() > 0)
doWorkIfNeeded();
}
function myNonEssentialWork (deadline) {
while (deadline.timeRemaining() > 0)
doWorkIfNeeded();
}
function myNonEssentialWork (deadline) {
while (deadline.timeRemaining() > 0 && tasks.length > 0)
doWorkIfNeeded();

if (tasks.length > 0)
requestIdleCallback(myNonEssentialWork);
}
/*Check:
https://developers.google.com/web/updates/2015/08/using-requestidlecallback
*/

‘requestIdleCalback’ calls your function providing it with a ‘deadline’ object, that has a method ‘timeRemaining’ which returns how many time we have left to run our tasks. When this function returns zero we can schedule another function with requestIdleCallback

If the browser is overloaded with work there’s no guarantee that our callback will ever run, so we can pass a ‘options’ object with a ‘timeout’ property that defines the maximum amount of time that the browser will wait to run our callback.

requestIdleCallback(myNonEssentialWork, {timeout:2000});

Then you can update your function to:

function myNonEssentialWork (deadline) {

while ((deadline.timeRemaining() > 0 || deadline.didTimeout) &&
tasks.length > 0)
doWorkIfNeeded();

if (tasks.length > 0)
requestIdleCallback(myNonEssentialWork);
}

The requestIdleCallback still hasn’t got much for browser support but there’s a shim available that basically falls back to ‘setTimeout’.

Sources:

The UI files

Ramblings on UI development

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store