Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Performance Audit attribution from third-party wrapping #7005
Feature request summary
Here's an example:
Upon investigation, we found that our Error Tracking plugin was causing Lighthouse to be confused about work being done in our customer's app. The plugin wraps several high-level functions, and the callbacks of,
Because Boomerang is wrapping the callbacks in
If we were to disable Error Tracking and re-load the same page, we can see the real attribution moves a lot to the Page and other scripts (as well as Boomerang), but the "cost" of Boomerang has decreased from 770ms to 127ms:
We were hoping there would be a way to change it so these wrapping functions don't get blamed for the entire callback cost. One idea would be to have a list of files or functions that could be excluded from "blame" if at the bottom of the stack, similar to library blackboxing.
We're not sure if that's feasible though:
The only other alternates we've come up with is better education (explaining the issue to the customer, which we're doing now), or disabling Boomerang's wrapping if Lighthouse is detected (which we'd prefer to not do).
I have a repro page here, which merely does a
I'm willing to work on this change, if there's agreement on a correct approach.
What is the motivation or use case for changing this?
How is this beneficial to Lighthouse?
Thanks so much for the detailed information and willingness to work with us @nicjansma !
I agree we should be trying to attribute these costs more accurately in Lighthouse core (and therefore PSI, etc) without needing the user to do any opting-in to a plugin/config/options.
Let's start with where the cost should be going and follow up with how we're not quite getting there yet.
There are a couple ways to look at this.
Does that sound right to everyone?
Assuming it does, fixing this is a bit tricky for a first-time contribution.
We will need to bring the same logic we have for tracking timer installations over in