Fast but not furious: debugging user interaction performance issues
- 1. Front-end Dev & Designer at Lunar Logic Anna Migas Google Developer Expert WebMuses core team
- 2. Anna Migas @szynszyliszys Fast but not furious: Debugging user interaction performance issues
- 4. Perceived performance First Meaningful Paint Time to interactive
- 5. Optimise Critical Rendering Path
- 6. Optimise Critical Rendering Path Use progress bars instead of spinners
- 7. Optimise Critical Rendering Path Use progress bars instead of spinners Have a placeholder content
- 8. Optimise Critical Rendering Path Use progress bars instead of spinners Have a placeholder content Start upload before user even decides to click the upload button
- 11. ! "
- 16. Perceived performance First Meaningful Paint Time to interactive Smooth at all times
- 17. Agenda 1. Why sometimes interactions feel slow 2. Browser rendering and frames 3. Types of triggered changes in the UI 4. How to test for interaction performance 5. Potentially dangerous user interface patterns
- 18. J A N K
- 20. 60 fps 1000/60 = ~16.6ms
- 21. 60 fps 1000/60 = ~16.6ms 120 fps 1000/120 = ~8.3ms iPad Pro, Razer smartphone
- 22. How can we help the browser to make it on time?
- 23. Of鍖oad the main thread BUS main thread (UI) background thread (heavy task)
- 24. Of鍖oad the main thread 1. Use Web Workers for heavy tasks 2. Optimise the main thread
- 25. Of鍖oad the main thread 1. Use Web Workers for heavy tasks 2. Optimise the main thread
- 26. If we interact with a page, a browser needs to start serving frames (ideally 60 or 120 per second)
- 27. What a frame consists of?
- 28. What a browser does during these steps?
- 29. Change happens, an event is 鍖red 1
- 32. Layout
- 33. Everything is rasterised and painted to the layers 4
- 34. Paint
- 35. Paint
- 36. Layers
- 37. What creates new layers? 1. 3D or perspective transforms 2. Animated 2D transforms or opacity 3. Being on top/a child of a compositing layer 4. Accelerated CSS filters 5. In special cases <video>, <canvas>, plugins 6. will-change CSS property
- 39. Every layer consumes memory. Use them wisely.
- 40. Compositing 5
- 41. Compositing
- 42. Compositing
- 43. Types of triggered changes
- 44. Layout change (Re鍖ow) (width, margin-top, left)
- 45. Paint change (Repaint) (background-color, box-shadow, background-image)
- 47. How to test if we have a problem?
- 48. 檎艶鍖o敬壊
- 49. 檎艶鍖o敬壊 can be quite obvious
- 50. but for Repaints we might need better tools
- 51. but for Repaints we might need better tools
- 52. Performance tab (Chrome or Firefox)
- 57. Performance monitor tab (Chrome)
- 58. What are the potentially dangerous UI patterns?
- 59. Animations 1
- 60. Animations 1. Dont overuse animations 2. Animate only transform and opacity if possible 3. For 120fps avoid requestAnimationFrame() 4. Dont animate elements below other nodes (like fixed headers) 5. Dont animate too many elements
- 63. Parallax effect 1. Causes Paint Storms 2. Almost always bad 3. Dont use scroll events 4. Dont use background-position 5. Use 3D transforms and perspective if you need to: https://developers.google.com/web/updates/ 2016/12/performant-parallaxing
- 64. Fixed elements 3
- 66. Fixed elements 1. Repaints with every frame when scrolling 2. Use will-change property (or transform: translate3D(0,0,0)) to avoid repainting .fixed-element { position: fixed; will-change: transform; }
- 68. Scrolling events 1. Dont attach wheel or touch listeners to the whole document, use smaller areas instead 2. Take advantage of passive event listeners (use with polyfill): window.addEventListener("scroll", func, {passive: true});
- 69. Hover effects 5
- 71. Hover effects 1. If they are bound to happen oftenyou might consider using will-change property 2. Can be deadly if there are too many and can be easily triggered 3. Avoid effects triggering Layout or Paint: https://csstriggers.com/
- 74. Appending elements 1. Make sure not many elements will be affected 2. Try to separate the area (will-change, contain: layout) 3. Try not to change the size of area (for example use overflow property)
- 75. Summary 1. Jank happens when the browser doesnt finish rendering a frame on time 2. Try to offload and optimise the main thread 3. Avoid content Reflows and Repaints 4. Dont overuse layers 5. Test your website with Performance, Layers and Rendering tabs 6. Use responsibly potentially dangerous UI patterns
- 76. Resources 1. http://jankfree.org 2. https://dev.opera.com/articles/css-will-change-property 3. https://www.udacity.com/course/browser-rendering-optimization-- ud860 4. https://www.html5rocks.com/en/tutorials/speed/layers 5. https://www.html5rocks.com/en/tutorials/speed/high-performance- animations 6. https://blog.logrocket.com/eliminate-content-repaints-with-the-new- layers-panel-in-chrome-e2c306d4d752