Looks like what's going on is that there's a constantly animating ad on the page which gets covered by the hamburger menu. However we fail to realize that the ad is fully obscured and keep ticking CSS animations for it at 60 fps. Each animation frame runs and decides there's nothing to render (EarlyOut_NoUpdates), which is why you only see only one actual frame being produced when the menu opens but several rAFs which don't lead to screen updates.

I think everything is working correctly here, but for efficiency we should start throttling frames that are fully covered by other elements. (Could we extend IntersectionObserver to do this?)

Deleted: trace_raf.json.gz 3.2 MB

trace_raf.json.gz 3.2 MB Download

IntersectionObserver v2 is planned (although unstaffed at the moment) to deal with occlusion detection. It's not clear how it will pan out since occlusion detecting is much more expensive. So, we'll have to evaluate once we have a prototype if it's performant enough to occlusion detect every iframe in the page that intersects with the viewport (for one's that don't intersect, we can skip the occlusion detection).

My intuition is that it'll work well, but we don't know till we build it. This might be a good starting point for prototyping IOv2 since it's an internal use case that we can iterate on and explore how it works on real content.

A more general intervention I've wondered is if we should throttle rAF for sites that are constantly ticking rAF but not painting anything new.