RootCauses Artifact is slow if there are lots of "SVG changed" invalidations

[mattzeunert]

FAQ

• Yes, my issue is not about variability or throttling.
• Yes, my issue is not about a specific accessibility audit (file with axe-core instead).

URL

https://lottiefiles.com/

What happened?

Run Lighthouse lighthouse https://lottiefiles.com/

The root causes gatherer takes 34 seconds

 LH:status Getting artifact: DevtoolsLog +7ms
  LH:status Getting artifact: Trace +0ms
  LH:status Getting artifact: RootCauses +0ms
  LH:status Getting artifact: Accessibility +34s
  LH:status Getting artifact: AnchorElements +670ms
  LH:status Getting artifact: ConsoleMessages +138ms

Counting the invalidations/prepaints:

{ eventsForLayoutInvalidation: 784184, prePaintEvents: 515 }

What did you expect?

I expected it to be faster.

What have you tried?

Some initial profiling on another lottie player site:

How were you running Lighthouse?

CLI

Lighthouse Version

11.6.0

Chrome Version

No response

Node Version

No response

OS

No response

Relevant log output

No response

[adamraine]

Definitely reproducible, looks like we are truing to get the node details of every layout invalidation node which is taking a while.

[adamraine]

For me Lighthouse takes ~4 minutes locally on https://lottiefiles.com/
Some optimizations in the root causes engine helped get that down to ~2:45 (~2 min of which is spent in root causes)

We should continue to iterate on the performance of the root causes engine, but https://lottiefiles.com/ also contains a lot of invalidation tracking events (specifically iframe added to dom events) that the root causes engine has to sift through. We may want to limit the root causes engine somehow since it's results are helpful but not vital.

[adamraine]

The performance should of RootCauses should be much improved with #15926 released in LH 11.7.1.

It might be possible to improve performance further, but I expected us to overhaul the root causes engine in the near future so I think we can close this.