Rendering Performance
summary
Target is 60 fps so each frame has a ~16.6 ms budget; any paint over that causes visible jank. Use Chrome DevTools’ timeline and continuous repainting to find spikes, prefer requestAnimationFrame over setTimeout, and batch paints to reduce frequency. Compositing (the translateZ hack) and GPU textures help but can backfire—image decode/resize and CPU→GPU uploads are common expensive hotspots. Measure, don’t guess: telemetry, webpagetest and jankfree.org are practical ways to reproduce, profile and validate fixes.
AI-written summary · about
chapters (22)
- 0:00Start
- 0:50Rendering Performance
- 1:32Chrome Dev Tools
- 2:06Jank
- 2:57Long Paints
- 3:51Etsy
- 5:37Request Animation Frame
- 5:52Support across Browsers
- 6:26Paint Less
- 8:46If There Were a Why Slow for Rendering Performance What Would Its Tests Be What Changes Would Be Easiest To Implement and Which Would Have the Biggest Impact
- 10:16Apply Specific Restriction
- 11:11Telemetry
- 13:27Css Transitions
- 26:53Synthetic Testing
- 28:16Gpu Benchmarking
- 36:02Garbage Collection
- 37:00Garbage Collection Api
- 40:23Main Thread
- 43:14Does It Need To Show All those 30 Images at Once
- 45:49Image Decoding
- 47:21What Have Been the Biggest Wins and Waste of Time at Real Websites
- 50:42Example Libraries
related talks
58mPanel 3: Performance
58mRendering performance from the ground up
39mPerformance Beyond Page Load
25mRendering Performance from the Ground Up
30mFast but not furious: debugging user interaction performance issues
31mJank Busters - Chrome Rendering Performance
32mDone in 0.0166666666 seconds
32mParallax Performance