Observing a similar behavior on some pages on tfl.gov.uk.

e.g. https://tfl.gov.uk/bus/stop/490012640M/fleet-street-city-thameslink

Trace attached. CPU time is again primarily spent in CompositingRequirementsUpdater::updateRecursive (~85ms per BeginMainFrame). Lots of BMFs seemingly caused by an animation but then aborted (no updates).

Deleted: trace_tfl.gov.uk.json.gz 7.5 MB

trace_tfl.gov.uk.json.gz 7.5 MB Download

I think this might be non-actionable. We need to do some work to determine if the animation is having any visible effects. And sometime there is animation running across the top of the screen. Repaint does not show untoward behavior.

chrishtr@, WontFix this?

Is the animation making no changes at all, or is it only affecting offscreen content?

For diego.one: The responsible animation seems to be on a :before element of a span with style "opacity: 0" (span.f37guwu::before). The span is on the screen, but invisible b/c of 0 opacity.

For tfl.gov.uk: There's a spinner (div.goog-te-spinner-pos) at "left: -1000px; top: -1000px" with an animated <svg> inside an "opacity:0" div (div.goog-te-spinner-animation).

I also came across another page today where animations are offscreen (https://euromat.com.pl/pol_m_Dzieci-Mlodziez-i-Art-Licencyjne-172.html), and causing a lot of CPU spent in Document::recalcStyle (trace attached).

Is there any way to avoid this work for such animations, or is this something that web developers have to take care of?

If the latter, do we (or should we) have a way to highlight such issues to developers e.g. in DevTools and/or Lighthouse? (+pfeldman and paulirish)

Deleted: trace_euromat.com.pl.json.gz 8.5 MB

trace_euromat.com.pl.json.gz 8.5 MB Download

It's an interesting point. There should be a way to avoid more work with
opacity:0 subtrees when the opacity itself is not animating.

Animation team, WDYT?