Presented at Web Unleashed 2017. More info at www.fitc.ca/webu Presented by Alexander Blom, Isle of Code Overview Adding animations to web and hybrid apps can be challenging. Aside from choosing technique, you are often left with jank and less than desirable performance. Objective Audience members will leave with a better understanding of animation performance & pitfalls desktop and mobile context. Target Audience Web/Hybrid developers looking to improve animation performance. Assumed Audience Knowledge Basic JS/CSS assumed Six Things Audience Members Will Learn What are my choices when needing to animate? What changes in a mobile context? What are the tradeoffs and how do I decide? What are the common pitfalls? How do I debug performance problems? Getting a smooth animation.

1. Animations for Web &
Hybrid
@alexblom
Isle of Code

2. whoami

3. Isle of Code
• Toronto + Houston based development;
• Focused on Ember/Vue/React/Cordova;
• Creators of ember-cordova & corber;

4. corber.io
• Extension of ember-cordova;
• Supports Ember, Vue, React, Glimmer;
• CLI for framework -> hybrid builds;
• Adds livereload, unified builds, splash/icons,
etc;

5. corber demo

6. Contents
• What makes a good animation?;
• Profiling / performance;
• 3 examples;
• Additional options (promoting layers, JS
animation API);

7. What makes a good
animation?

8. FPS Target
• 60fps is considered best;
• 1000ms / 60fps = ~16.6ms per frame;
• 60fps is not always achievable!;
• It is better to deliver a consistent frame rate
than a variable one. Consider targeting 30fps;

9. Animation Options
• Declarative: CSS;
• Generally speaking most performant;
• Browser knows what is happening up front -
can save you from yourself;
• Can become complex to write;

10. Animation Options
• Imperative: JS;
• Tell the browser how. Easier to spell out in
code (e.g. bounce);
• Run on the main thread (not great);
• requestAnimationFrame & webAnimationsAPI
can fix performance issues - to be discussed
later;

11. Profiling / Performance

12. From 0 to rendered

13. How our content is rendered
• 1: DOM Tree constructed;
• 2: Layout (recursively from the top left);
• highly interdependent;
• expensive;

14. Layout Styles
width overflow/overflow-y
min-width font-weight
height font-size
min-height text-align
padding line-height
display vertical-align
border white-space
border-width clear
position bottom/top/left/right
float

15. Reflow

16. What causes Reflow?
• Resizing the browser window;
• using JavaScript methods involving computed
styles;
• adding or removing elements from the DOM; and
• changing an element's classes.
• https://developers.google.com/speed/articles/
reflow

17. How our content is rendered
• 1: DOM Tree constructed;
• 2: Layout (recursively from the top left);
• 3: Paint;

18. Paint Styles
border-style outline
border-radius outline-color
background outline-width
background-size outline-style
background-image color
background-repeat visibility
background-position text-decoration
box-shadow

19. Paint Styles
• opacity is a special case;
• If the element has its own layer, this is handled
automagically by lowering the alpha-mask value;

20. How our content is rendered
• 1: DOM Tree constructed;
• 2: Layout (recursively from the top left);
• 3: Paint;
• 4: Composite/Layering (default is a single layer);

21. Layers
• Default is a single layer;
• Composed layer more efficient to animate - GPU;
• Pushing every node to it’s own layer is the worst case;
• The most performant is hardware accelerated
properties on composite layers (e.g. transform/
translateX);
• Layers are expensive (width * height * 3);

22. Promoting a Layer
• will-change property, e.g.;
• will-change: auto;
• will-change: scroll;
• will-change: transform;

23. Prior Layers

24. Add will-change;

25. Layers

26. Layout Thrashing

27. Layout Thrashing

28. Profiler Tool

29. Profiler Tool

30. Profiler Tool

31. Profiler Tool

32. Profiler Tool

33. Our Scene
https://www.sitepoint.com/playing-with-fire-organic-css3-animation/

34. Animation 1 -
The worst case

35. Animation 1

36. Animation 1

40. Some of our problems
• Big FPS dip;
• Each animation is triggering a reflow;
• We are not taking advantage of hardware-
accelerated properties;
• We are redrawing at a fixed (but not) rate;
• Will keep running in an unfocused tab;

41. We are redrawing at a fixed
rate
• Sort of:
• interval timing is not guaranteed - if our thread
is busy it will take longer;
• When a tab is inactive the interval will still fire
every ~1s;

42. CSS3 Animations
(@keyframe)

43. https://www.sitepoint.com/playing-with-fire-organic-css3-animation/

44. CSS3 Animation
• animation-duration;
• animation-delay;
• animation-timing;
• ease, linear, ease-in, ease-out, ease-in-out,
cubic-bezier;

45. Why don’t we try them
in this case?

46. But CSS animations
are hard!

47. Animation API

49. Animation 2 -
Hardware Accelerated

50. http://slides.com/ehayman/deck-1#/6

51. http://slides.com/ehayman/deck-1#/6

52. Animation 2

54. Timeline

56. Profile
• 6248ms to 5420ms on scripting;
• 10588ms to 4818ms rendering;
• 267ms to 1488ms painting;

57. Some of our problems
• Big FPS dip (sort of);
• Each animation is triggering a reflow;
• We are not taking advantage of hardware-
accelerated properties;
• Will keep running in an unfocused tab;
• We are redrawing at a fixed rate;

58. Animation Frames

59. animationFrame
• Supported for major browsers;
• Only draws when:
• the animation will be visible;
• the browser is ready;
• there are no other frames waiting to be drawn;
• Eliminates unnecessary draws & overloaded
callbacks;

61. animationFrame

62. animationFrame

65. Profile
• 5420ms to 2605ms on scripting;
• 4818ms to 5295ms rendering;
• 1488 to1557ms painting;

66. Some of our problems
• Big FPS dip;
• Each animation is triggering a reflow;
• We are not taking advantage of hardware-
accelerated properties;
• This will keep running in an unfocused tab;
• We are redrawing at a fixed rate;

67. Still could be better
• Immediate reaction may be to tear down unused
elements;
• Don’t

69. Demo

71. Profile
• 2605ms to 1068ms on scripting;
• 5295ms to 2100ms rendering;
• 1557 to 702ms painting;

72. Intersection Observer API

73. Intersection Observer API
• “The Intersection Observer API provides a way
to asynchronously observe changes in the
intersection of a target element with an ancestor
element or with a top-level document’s.”
• https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API

74. Intersection Observer API

75. Intersection Observer API
• callback function receives a list of intersections
detected;

76. Passive Event Listener

77. Passive Event Listener
• Allows you to indicate preventDefault will not be
used - e.g. eliminates block on scroll

78. My best practices
• Avoiding JS Animation API until better Safari support;
• Pages with smaller animations (e.g. button bounce):
• CSS/Hardware accelerated animations are fine;
• Will generally promote frequent/transitional
animations to their own layer;
• Pages with lots of animations:
• Just use animationFrame;

79. Animations for Web &
Hybrid
@alexblom
Isle of Code