Fullstack 2018 - Fast but not furious: debugging user interaction performance issues
- 1. Front-end Dev & Designer at Lunar Logic Anna Migas Google Developer Expert
- 2. Anna Migas @szynszyliszys Fast but not furious: Debugging user interaction performance issues
- 5. Perceived performance First Meaningful Paint Time to interactive
- 6. Optimise Critical Rendering Path
- 7. Optimise Critical Rendering Path Use progress bars instead of spinners
- 8. Optimise Critical Rendering Path Use progress bars instead of spinners Have a placeholder content
- 9. 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
- 12. ! "
- 17. Perceived performance First Meaningful Paint Time to interactive Smooth at all times
- 18. 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
- 19. J A N K
- 21. 60 fps β¨ 1000/60 = ~16.6ms
- 22. 60 fps β¨ 1000/60 = ~16.6ms 120 fps β¨ 1000/120 = ~8.3ms iPad Pro, Razer smartphone
- 23. How can we help the browser to make it on time?
- 24. Ofο¬oad the main thread BUS main thread (UI) background thread (heavy task)
- 25. Ofο¬oad the main thread 1. Use Web Workers for heavy tasks 2. Optimise the main thread
- 26. Ofο¬oad the main thread 1. Use Web Workers for heavy tasks 2. Optimise the main thread
- 27. If we interact with a page, a browser needs to start serving frames (ideally 60 or 120 per second)
- 28. What a frame consists of?
- 29. What a browser does during these steps?
- 30. Change happens, an event is ο¬red 1
- 33. Layout
- 34. Everything is rasterised and painted to the layers 4
- 35. Paint
- 36. Paint
- 37. Layers
- 38. 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
- 40. Every layer consumes memory. Use them wisely.
- 41. Compositing 5
- 42. Compositing
- 43. Compositing
- 44. Types of triggered changes
- 45. Layout change (Reο¬ow) (width, margin-top, left)
- 46. Paint change (Repaint) (background-color, box-shadow, background-image)
- 48. How to test if we have a problem?
- 49. Reο¬ows
- 50. Reο¬ows can be quite obviousβ¦
- 51. β¦but for Repaints we might need better tools
- 52. Performance tab (Chrome or Firefox)
- 53. Performance tab (Chrome or Firefox)
- 58. Performance monitor tab (Chrome)
- 59. What are the potentially dangerous UI patterns?
- 60. Animations 1
- 61. Animations 1. Donβt overuse animations 2. Animate only transform and opacity if possible 3. For 120fps avoid requestAnimationFrame() 4. Donβt animate elements below other nodes (like fixed headers) 5. Donβt animate too many elements
- 64. Parallax effect 1. Causes Paint Storms 2. Almost always bad 3. Donβt use scroll events 4. Donβt use background-position 5. Use 3D transforms and perspective if you need to: https://developers.google.com/web/updates/ 2016/12/performant-parallaxing
- 65. Fixed elements 3
- 67. 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; }
- 69. Scrolling events 1. Donβt 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});
- 70. Hover effects 5
- 72. Hover effects 1. If they are bound to happen oftenβyou 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/
- 75. 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)
- 76. Images 7
- 78. Images A. Can be downloaded in unexpected ways B. Can cause content jumps on load C. Often are optimised incorrectly
- 80. Images: downloads β’ Semantics = performance β’ How image is embedded (img tag/background- image) influences the time of download β’ Comprehensive research by Harry Roberts
- 81. Images: downloads (img tag) <img src=βimage.pngβ alt=βAlt textβ>
- 82. Images: downloads (background img) background-image: βimage.pngβ;
- 85. Images: content jumps β’ No jumps in Chrome any more (scroll anchoring enabled by default in Chrome 56) β’ Can be avoided by using a placeholder content eg. created with the intristic ratio: img-height / img-width * 100% .container { padding-bottom: $intristic-ratio; height: 0; overflow: hidden; }
- 87. Images: optimisation β’ Less images = better performance β’ Use correct format β’ Make sure optimisation is the very last step (see @kornelski https://pitercss.com/ talk once it is released)
- 88. Takeaways 1. Jank happens when the browser doesnβt finish rendering a frame on time 2. Try to offload and optimise the main thread 3. Avoid content Reflows and Repaints 4. Donβt overuse layers 5. Test your website with Performance, Layers and Rendering tabs 6. Use responsibly potentially dangerous UI patterns
- 89. 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 7. https://dassur.ma/things/120fps/