Browser Rendering Optimizations for Front-end Development

Before a user can interact with a web application, it has to be loaded first. This is the first stage in the app lifecycle and it is important to aim at reducing (ideally at 1s) the load time to the smallest number possible.

After an application is loaded, it usually becomes idle; waiting on the user to interact with it. The idle block is usually around 50ms long and provides the developer with the opportunity to do the heavy lifting, such as the loading the assets (images, videos, comments section) that a user might access later.

When the user starts interacting with the application and the Idle stage is over, the application has to react properly to user interaction (and input) without any visible delay.

A challenge might be posed when the response to user interaction involves animation of some sort. In order to render animations that execute at 60 frames per second, each frame would have a limit of 16ms.

In reality, this should be about 10ms–12ms due to the browser overhead. A way of achieving this would be to perform all animation calculations upfront (during the 100ms after a UI element has been interacted with).

JavaScript allows developers to provide users with animations and visual experiences and is therefore heavily used in web applications. From our discussion on the app lifecycle, we see that the browser has about 10ms–12ms to render each frame. To ease the burden of JavaScript on the rendering pipeline, it is important to execute all JavaScript code as early as possible in every frame since it could trigger other areas of the rendering pipeline.

It is possible to achieve this using the window.requesAnimationFrame() method, according to the MDN web docs:

"The window.requestAnimationFrame() method tells the browser that you wish to perform an animation and requests that the browser calls a specified function to update an animation before the next repaint. The method takes a callback as an argument to be invoked before the repaint.

The requestAnimationFrame() API enables the browser to bring in JavaScript at the right time and prevent itself from missing a frame. Here’s an example of the method in use:

function doAnimation() {
    // Some code wizardry
    requestAnimationFrame(doAnimation); // Schedule the next frame

}

requestAnimationFrame(doAnimation);

The performance tab in the Chrome DevTools allows developers to record a page while in use and displays an interface that shows how JavaScript performs in the web application.

While requestAnimationFrame is a very important tool, some JavaScript code could be really resource intensive. Websites run on the main thread of our operating systems hence these scripts could stall the execution of other stages of the rendering pipeline. To solve this problem, we can use Web Workers.

Web Workers allow us to spawn new threads for resource-intensive JavaScript code according to the MDN web docs:

"Web Workers is a simple means for web content to run scripts in background threads. The worker thread can perform tasks without interfering with the user interface.

Once created, a worker can send messages to the JavaScript code that created it by posting messages to an event handler specified by that code (and vice versa)."

To use this feature, you’ll need to create a separate JavaScript file which your main app will spawn into a Web Worker.

Style changes are a key part of any web application’s rendering pipeline as the number of style changes required by its elements is directly proportional to the performance cost of style recalculation.

Check out CSS Triggers for a breakdown of how CSS styles affect the rendering pipeline and therefore performance.

In addition to the number of style changes, selector matching should be factored into our list of rendering optimizations. Selector matching refers to the process of determining which styles should be applied to any given DOM element(s).

Certain styles may take more time to be processed than others and this becomes important as the number of elements affected by one or more style changes increases.

A suitable approach to solve this issue is the Block Element Modifier (BEM) methodology. It provides great benefits for performance as class matching, which follows the BEM methodology, is the fastest selector to match for modern browsers.

A major performance bottleneck is layout thrashing. This occurs when requests for geometric values interleaved with style changes are made in JavaScript and causes the browser to reflow the layout. This, when done severely in quick succession, leads to a forced synchronous layout.

In this article, Googler, Paul Lewis, highlights the various optimizations that can be done to prevent forced synchronous layouts.

Painting occurs when the browser starts filling in screen pixels. This involves drawing out all visual elements on the screen. This is done on multiple surfaces, called layers. Paint could cause performance problems when it is required by large portions of the page, especially at intervals, as seen during page scrolling.

The paint profiler, as shown above, makes it easy to identify what areas of the page are being painted and when they’re being painted. The paint profiler can be found by pressing the ESC key after navigating to Chrome DevTools and selecting the Rendering tab.

The first checkbox, Paint flashing, highlights in green what areas of the page are currently painted and the frequency of this could tell us if painting contributes to the performance issues on the rendering pipeline.

Looking at this image, we can see that only the scroll bar is painted as the page is scrolled, which indicates great browser paint optimizations.

This is the final path in the browser rendering pipeline and it involves an important browser structure — Layers. The browser engine does some layer management by first considering the styles and elements and how they are ordered, then tries to figure out what layers are needed for the page and updates the layer tree accordingly.

Next, the browser composites these layers and displays them on the screen. Performance bottlenecks due to painting occur when the browser has to paint page elements that overlap one another and also exist in the same layer as one another.

To solve this problem, the elements involved will have to exist in separate layers. This can be achieved with the will-change CSS property and setting its attribute to transform:

<element_to_promote> {
    will-change: transform;
}

It should, however, be noted that an increase in layers would mean an increase in the time spent on layer management and compositing. With Chrome DevTools, it is possible to see all the layers on a page as shown below:

To get to the Layers tab, click on the hamburger menu button (three vertical dots) in Chrome DevTools, navigate to “More tools”, and select “Layers”.