LoAF
summary
LoAF (Long Animation Frames) gives per-frame timings plus script-level attribution so pages can show which scripts actually cause slow frames and how often, not just total JS bytes. It exposes script execution entries (scripts >500 ms), reports blocking duration / derived TBD-style metrics, and surfaces extreme cases — one page produces 21,000 long frames in an hour. It requires RUM, runs in Chromium-family browsers today, and has limits (no cross-origin stack details, opaque extension work, no GC attribution, and the first long-frame handling needs care).
AI-written summary · about
chapters (32)
- 0:00LoAF introduction
- 1:03JavaScript growth costs
- 3:37Long Tasks API limits
- 4:17Introducing LoAF
- 5:21Measuring frame time
- 6:47LoAF phases
- 9:39LoAF lifecycle
- 11:06LoAF before DOM load
- 12:30JS execution in real data
- 13:56LoAF outliers
- 16:03LoAF browser support
- 16:47Detecting user interactions
- 17:52Input delay estimation
- 18:37Introducing TBD
- 21:07Refining TBD
- 21:49TBD thresholds
- 22:10LoAF frame rates
- 23:15LoAF key questions
- 23:59Problematic scripts
- 26:05Selfridges Next.js case
- 27:30Debugging multiple scripts
- 28:34Slow interactions debugging
- 31:04Linking LoAFs to Interaction to Next Paint
- 33:13Script attribution challenges
- 34:39Source URL directive
- 35:44Limitations with extensions and garbage collection
- 36:49LoAF tools
- 37:32Why LoAF matters
- 38:37LoAF future
- 39:41Q&A targets
- 41:26Q&A slow functions
- 42:49Q&A framework adoption
related talks
44mFast but not Furious: Debugging User Interaction Performance Issues
39mPerformance Beyond Page Load
14mPage performance after load
30mFast but not furious: debugging user interaction performance issues
49mEffortless Performance Debugging
31mWatch your back, Browser! You're being observed
16mCoding Session: Stunning Performance
22m#notalljavascript (How to deal with 3rd party JS)