Fast but not Furious: Debugging User Interaction Performance Issues
summary
Argues that perceived performance is about post‑load interactions and shows concrete debugging steps: measure frames with Chrome Performance and Layers and Firefox perf tools, inspect frame budget ≈16ms for 60fps (120fps halves it), and find paint storms (parallax causes full repaints). Recommends concrete fixes: offload work to web workers, promote animated elements to layers with use transforms and opacity, avoid excessive layers, prefer CSS/Web Animations over rAF on high‑refresh devices, and validate with paint flashing and the Layers/Rendering panes.
AI-written summary · about
chapters (27)
- 0:00Intro
- 0:11Anna Migas
- 5:07Perceived performance
- 9:33What a frame consists of?
- 11:58What creates new layers?
- 15:12Layout change (Reflow)
- 15:53Paint change (Repaint)
- 16:22Compositing change
- 17:01Reflows can be quite obvious...
- 18:04Performance tab (Chrome or Firefox)
- 19:09Layers tab (Chrome)
- 19:51Rendering tab (Chrome)
- 20:30Paint flashing (Firefox)
- 20:54Performance monitor tab (Chrome)
- 22:32Animations
- 23:14requestAnimation Frame
- 25:58Parallax effect
- 26:46Fixed elements
- 27:31Scrolling events
- 29:45Hover effects
- 31:30Appending elements
- 34:11Images: downloads (img tag)
- 34:28Images: downloads (background img)
- 36:13Images: content jumps
- 37:58Images: lazy loading
- 38:54Takeaways
- 40:06Resources
related talks
30mFast but not furious: debugging user interaction performance issues
30mFast but not furious: debugging user interaction performance issues
39mPerformance Beyond Page Load
49mEffortless Performance Debugging
47mRendering Web Performance
32mParallax Performance
59mRendering Performance
58mPanel 3: Performance