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

Aircraft Capacity Range miles Speed mph Debit cap x mph
Boeing 777 375 4630 610 228.700
Boeing 747 470 4150 610 286.700
Concorde 132 4000 1350 178.200
DC-8-50 146 8720 544 179.424

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

Page load

  • SPDY / HTTP 2
  • Concat + minify JS & CSS
  • GZIP
  • CDN
  • Image sprites
  • Cache-busting
  • Lazy load
  • Scripts at the end & styles at the start

Runtime

  • Transitions & animations
  • Scrolling
  • Resizing
  • Number of DOM elements
  • DOM rendering & manipulation
  • Memory & GC

Rendering operations

  • Recalculate style
  • Layout
  • Paint setup & Paint
  • Composite layers
DevTools

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

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

DevTools properties

Animate like a boss

Like a boss

Animate properties that only require Composite Layers.

Avoid others, specially the ones that require Layout.

Animate like a boss

Cheap operations

Animate like a boss

DEMO

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

DEMO

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