VelocityConf: Rendering Performance Case Studies

Rendering Performance Case Studies Gone in 60 frames per second

Addy Osmani - @addyosmani Chrome Developer Relations Google

Network Compute Render 3 Pillars Of Performance

Our agenda for today... 1. DOM to pixels on the
screen 2. Rendering performance tooling 3. Real-world case studies Flickr Bootstrap Pitchfork Pinterest Google+

#perfmatters

What we build for the web is evolving.

Users ❤ snappy experiences.

Silky smooth scrolling Buttery animation Great performance everywhere. High performance
web apps have:

Speed must be treated as an essential design feature.

The fastest web page is..

Everything we add increases the work the browser has to
do to put pixels on the screen

Mobile web performance goals 1. Connectivity - Show above the
fold content in < 1s - Serve critical path CSS in first 14KB 2. Max of 200ms server response time 3. 60fps scrolling, 60fps transitions 4. Speed index under 1000* * average time visual parts of the page display per WebPageTest

Today we’ll focus on this. 1. Connectivity - Show above
the fold content in < 1s - Serve critical path CSS in first 14KB 2. Max of 200ms server response time 3. 60fps scrolling, 60fps transitions 4. Speed index under 1000

Rendering performance impacts user experience.

"In an A/B test, we slowed down scrolling from 60fps
down to 30fps. Engagement collapsed" ~ Shane O'Sullivan * in their native app, ﬂuctuating between 30 to 45fps. * Consistent 30fps performed second best

"We tested pre-fetching JS in search results, which caused jank
in our pages. All business metrics got worse" ~ Jonathan Klein

Response rates matter.

See the flow of how Chrome renders pages

DevTools Timeline

drag here to ﬁlter record/stop 30fps = 33ms per frame,
60fps = 16ms per frame

what do these records mean?

Let’s dive in!

Parse HTML

GET / HTTP /1.1 host: www.example.com Make a request

<!DOCTYPE html> <html class="no-js"> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge">
<title>MA RESPONSE</title> <meta name="description" content=""> <meta name="viewport" content="width=device-width, initial-scale=1"> <link rel="stylesheet" href="css/main.css"> </head> <body> <section> <h1>HTML wizaaaaard</h1> <p>I am teh HTML masterz.</p> </section> </body> </html> Get a response

<!DOCTYPE html> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <title MA RESPONSE</title>
<meta name="description" content=""> <meta name="viewport" content="width=device-width, initial-scale=1"> <link rel="stylesheet" href="css/main.css"> </head> HTML wizaaaaard</h1> I am teh HTML masterz.</p> </section> </body> </html> Parse HTML Get a response <html> <head> <title> <link> <body> <section> <h1> <p>

<html> <body> <script> <section> <h1> <img> <p> <head> <title> <link>
Get a response

Recalculate Style

DOM CSS + Recalculate Style Styling the DOM

Render tree Styling the DOM

<html> <body> <section> <h1> <img> <p> Styling the DOM

<html> <body> <section> <h1> <img> Styling the DOM section p
{ display: none; }

<html> <body> <section> <h1> <img> Styling the DOM section h1:after
{ content: "<333 pseudo elemz" } <h1:after>

Layout

html, body { marg: 0; width: 300px; height: 700px; background:
white; color: white; } body { background: #888; } section { display: block; margin-top:30%; padding-top:60px; width:100%; background:#444; } section h1:after{ content: '<3 pseudo'; height: 40px; margin-top: 10px; display: block; } img { margin: 30px; border-radius: 4px; border: 3px solid white; box-shadow: 0 2px 2px rgba(0,0,0,3); } Layout Laying out the document

Rasterizer Raster

drawPoints drawOval drawRectangle drawRoundedRect drawPath drawBitmap drawText drawLine drawArc clear
translate save restore clipPath moveTo lineTo Rasterizer

Rasterizer

Instant replay

Image Resize

Image Decode + Resize Draw Bitmap

Move Elements

Composite Layers

Composite Layers Layers

Layer creation criteria

To the screen

To the screen CPU GPU Composite Layers

All together, you should expect to see..

width margin border left/top box-shadow border-radius background outline transform opacity

DOM to pixels on the screen Recalc styles Calc styles
that apply to elements Layout Generate geometry for each element Paint Fill pixels for each element into layers (Paint) Composite layers Draw layers out to the screen

What about frame rate?

Frame rate Rate at which a device produces consecutive images
to the screen

To see what’s impacting rendering, look at FPS

A consistent frame rate is our ideal

Why target 60fps?

Match the refresh rate of the devices you are targeting.

Jank Disruption in consistent frame rate that manifests itself visually

< 15fps Your users will perceive jerkiness and jank

30fps Smooth as long as it’s a constant 30fps

60fps Smooth animations and transitions with no stutter

Frame budget At 60fps, you have 16.7ms budget for Logic
processing Compute processing Rendering

Frame budget It’s more like 8-10ms budget because - Browser,
JS engine, renderer processes - Margin for slower devices like mobile.

What causes jank?

Properties that trigger layout (reflow) Correct as of November, 2013.

Correct as of November, 2013. Reading oﬀsetTop in a loop

Correct as of November, 2013. Cache that read outside loop
or don’t use oﬀsetTop

Drop-shadows Blurs Linear-gradients Fixed background images Heavy styles can cause
jank* *Correct as of November, 2013. Likely to change!

CSS Styles that affect paint, layout

Recalculate style triggered when styles are computed or changed. Heavy
use of JS to rearrange the page (e.g onscroll) is bad

Heavy onscroll() handlers Doing shit inside of scroll is terrible

Scrolling Correct as of November, 2013. Watch out for: Unnecessary
paints: position:fixed overflow:scroll hover effects touch listeners Long paints: Complex CSS Image decodes Large empty layers

Long image decodes and resizes Remember to pre-scale your images!

Should be pre-scaled. Instead using overly high-res sources with more
costly resizes.

DOM elements with measurably high paint cost Measure what elements
might be slowing you down.

Too much inside your event handlers

Heavy animation or data processing Where possible rely on rAF
or Web Workers

Position transform: translate(npx, npx); Scale transform: scale(n); Rotation transform: rotate(ndeg);
Opacity opacity: 0....1; 4 things a browser can animate cheaply Move all your visual effects to these things. Transition at your own risk. translateZ(0) or translate3D() may be required

Hardware acceleration GPU compositing

Old-skool painting All your elements get painted into one big
bitmap

Old-skool painting What if we had separate bitmaps, or "layers"?
Click.

Layers & Compositing Hardware compositing uses the GPU to help
build the page Elements are broken out to a bunch of layers Those layers are uploaded to the GPU as textures The GPU composites those textures together

More: DevTools Settings

Useful Settings red shaded rectangles around repainted regions orange borders
around composited layers yellow border around touch handler listeners

Layer promotion hacks -webkit-transform: translateZ(0); -webkit-transform: translate3d(0,0,0); 1 -webkit-transform: translate3d(0,0,0)
Use with caution!! Blink/Webkit iOS -webkit-perspective: 1000; -webkit-backface-visibility: hidden; 1 -webkit-transform: translate3d(0,0,0)

New! Layers panel Visualize elements promoted to a layer with
the new layers panel (experimental)

Layout thrashing

When JS violently writes, then reads from the DOM repeatedly
causing reflow

The slow way while (i--) { var greenBlockWidth = sizer.offsetWidth;
ps[i].style.width = greenBlockWidth + 'px'; }

The right way var greenBlockWidth = sizer.offsetWidth; while (i--) {
ps[i].style.width = greenBlockWidth + 'px'; }

Writes to the DOM invalidate layout Browser wants to wait
until the end of the current frame to reflow.

Querying geometric values before a frame completes, forces early layout.
Forced synchronous layout

It’s a performance killer.

FastDOM Batches DOM reads/writes on the next frame using rAF
for scheduling.

~ Paul Irish

Case studies

Don’t guess it, test it!

Case study: Flickr with thanks to Scott Schiller @ Flickr

Web seeing a trend of vertical parallax effects.

inception-explained.com

flickr.com (optimized)

But scroll used to be significantly slower.

For each Y pixels of vertical axis scrolling, move an
absolutely positioned image in the same direction.

For each Y pixels of vertical axis scrolling, move an
absolutely positioned image in the same direction. window.onscroll() backgroundPosition marginTop or el

window.onscroll = function(e) { var parallax = document.getElementById('parallax-background'); parallax.style.marginTop =
(window.scrollY/2) + 'px'; } Minimal parallax example

Neither marginTop or backgroundPosition alone perform well. They don’t use
hardware compositing.

Demo (slow)

Timeline view

Have the GPU help with accelerating compositing of the expensive
parts Trick

Elements can be promoted to a layer using translateZ() or
translate3D() Avoid expensive paints Reminder

window.onscroll = function(e) { var parallax = document.getElementById('parallax-background'); parallax.style.transform =
'translate3d(0px,' + (window.scrollY/2) + 'px, 0px)'; } Optimized parallax example

Promoting the element to a new layer

Demo (fast)

Timeline view

Twitter Bootstrap 3

background- image: linear- gradient( to bottom, #ffffff, #e6e6e6);

100% faster paint time.

BS3 much more viable for sites that need to work
well on under-powered mobile and tablet devices

Pitchfork

Why is scrolling in this Daft Punk site so slow?

Image shipped (high-res) Size actually needed High image resize cost

Pre-scale images where possible to avoid resize cost.

Live case study: Pinterest

Post-optimization Great scrolling performance

Pre-optimization

Sub-optimal position:fixed use causing unnecessarily large repaints Slow scrolling due
to excessive use of styles (currently) expensive to paint Doing a lot during hover on scroll Main issues

Case study: Google+ with thanks to Steve Kobes @ Google+

Perf went from 12fps to 60fps

Jank bustin’

Simplified G+ layout

Simplified G+ layout position:fixed position:fixed

Problem.

A position:fixed element causes a repaint when moved within its
layer.

To avoid the repaint, put the element in its own
layer.

Simplified G+ layout translateZ(0) translateZ(0)

Caveats of translateZ - more layers = more time compositing
layers - text anti-aliasing requires an opaque background within the layer - triggers Safari positioning bugs inside iframes

Too many layers? Sometimes a style creates compositing layers for
all positioned descendants.

Another problem.

G+ styles for card-flip animation

-webkit-backface-visibility: hidden

Causes every descendent element to get its own layer

Remove it, apply it through JS for duration of the
card animation The Fix!

one last problem

Forced synchronous layouts Modifying the DOM invalidates layout. element.innerHTML =
'...'; // Layout invalidated.

Measuring the DOM depends on the layout If previously invalidated,
this forces synchronous layout (since execution cannot continue until the correct value is obtained). alert(element.offsetHeight); // Layout forced.

G+ reduced synchronous layouts cards.forEach(function(card){ appendHTML(card); measure(card); }); write read
write read.. cards.forEach(function(card){ appendHTML(card); }); cards.forEach(function(card){ measure(card); }); write write read read.. They reduced them from O(n) to O(1) by refactoring a loop

Forced Synchronous Layouts Timeline shows where your code is causing
synchronous layouts Remember to scroll down for the second stack trace.

Bonus optimization Animate with translate instead of left/top

Paint performance tooling in other browsers

There’s now lots of tooling to improve the responsiveness of
your UIs. BROWSER SUPPORT CATS HAVE BEEN LISTENING

IE F12 Developer Tools UI Responsiveness Tool shows frame rate

Firefox DevTools: Paint flashing Highlight areas being painted

WebKit Nightlies: Paint counts of layers

WebKit Nightlies: Reasons for compositing

Audience check

In summary...

Frame rate matters and can impact engagement

Don’t over-do layout. Do reads before writes.

Be mindful of paint costs. Use the DevTools.

Check your perf on desktop and mobile.

Mobile-first performance benchmarking Test on low-end hardware. Get 60fps there.

DevTools Remote Debugging

If you’re building something, set performance objectives up front.

Hit those objectives, add tests to measure and then never
regress!

If all goes well, this could be you!

To learn more checkout jankfree.org

Use tools. not rules.

Thank you. @addyosmani +AddyOsmani

VelocityConf: Rendering Performance Case Studies

VelocityConf: Rendering Performance Case Studies

More Decks by Addy Osmani

Other Decks in Programming

Featured

Transcript