KISS

(keep it smooth stupid)

Frontend performance on web applications

by André Cruz / @satazor

Performance

Is an ambigious word, depends on what we are trying to achieve

• Performance é uma palavra ambígua, depende das condições e objectivos
• Qual o melhor avião? Qual é o que tem melhor performance?

Performance on the web

.. really matters

• User demands and expecations are high
• Users don't like slow and slugish experience
• New technology empower us to make rich and interactive web applications

• Performance nas aplicações resume-se a duas fases: Page load e Runtime
• YSlow da YAHOO ajuda no Pageload
• DevTools ajuda no Pageload mas principalmente no Runtime

Rendering operations

All of this in <16ms on a 60hz monitor to avoid loosing frames

• Sequencia de operações de renderização
• Em geral, funciona em waterfall mas pode começar directamente numa das fases

Recalculate style

Matches the CSS styles with the DOM structure

Everytime a CSS property changes

Usually a fast operation, slower on complex CSS selectors

Layout

Calculation of positions and geometry

When certain CSS properties change, e.g.: width, height, top, left, margin

Takes longer when the DOM structure is very complex

Paint Setup & Paint

Fill out the pixels for each element into layers

When certain CSS properties change, e.g.: color, border-radius, background

Takes longer when using inefficient styles

Slower on low end devices

Composite layers

Draw layers into the screen

When certain CSS properties change, e.g.: transform, opacity

Very cheap to do

Animate like a boss

Animate properties that only require Composite Layers.

Avoid others, specially the ones that require Layout.

Animate like a boss

Animate like a boss

Layout trashing

When the DOM is modified via JavaScript it is marked as dirty. The browser is lazy and wants to wait until the end of current operation or frame to handle the modifications

If we ask for a value back from the DOM before that we force the browser to handle it early

If you abuse it, you are doing layout trashing

Layout trashing

More severe in a large decoupled code base where each component handle its rendering and measurement independently.

To counter this you may use FastDom, a library that queues reading and writing operations and groups them.

Scroll

Avoid expensive styles that slow down painting

GPU accelerate the layer with transform: translateZ(0)

Turn off hover effects that may trigger during scroll

Don't do anything more than getting a scroll offset in the scroll event handler, delay the rest to a requestAnimationFrame or use a throttler

On mobile, overflow: auto performs poorly, use -webkit-overflow-scrolling: touch

Scroll

Resize

Turn off animations during the resize

Avoid doing a lot of work, delay stuff using requestAnimationFrame or use a throttler

Pay special attention to layout trashing when adapting to resolutions dynamically via JavaScript

Memory & GC

Avoid unnecessary allocations of objects, arrays or other structures

GC blocks the main thread which usually also blocks the UI thread

The higher the unnecessary memory allocated, the longer the Gargabe Collection cycle will take

If your memory is unexpectedly high, check for memory leaks using the DevTools Memory profiling

Do not guess, test it!

Because browsers are always evolving and the things you know today may no longer apply

Each case should be treated separately