Audit: Add JS coverage audit

[patrickhulce]

JS coverage has landed in the protocol and can be added as a similar byte efficiency audit to CSS usage.

[ebidel]

@patrickhulce is this something we can reignite? Is the protocol API in a good spot?

Do you want to take it? Or I can if you prefer.

[patrickhulce]

not sure, the protocol hasn't really changed since the initial changes and we punted the CSS out, @paulirish any objections to bringing this in? might be trickier now though since last I checked enabling the tracking and noticeable perf impact and we're down to a single pass

[patrickhulce]

@ebidel just an update here after speaking with caseq, there's a potentially significant performance impact of enabling the coverage, so I'm going to investigate with some weak devices on plots and see how it impacts the numbers. I still have my local branch with the coverage fixes from way back, so its really a matter of ensuring we can continue as previously planned.

[ebidel]

Coolio. Even if new audits (like this) turn out to be slow, it would be beneficial for us to have them in the codebase for users to run. Maybe they're opt-in or something.

[mixed]

Hi. @patrickhulce
I look forward to the completion of this work(CSS|JS coverage).🙏 Is this job currently stopped?

[patrickhulce]

@mixed yes currently blocked on review, the CSS coverage updates are in #2518 and I will rebase my local JS coverage against in once it's merged

[rviscomi]

@patrickhulce is this live? I'm checking the extension and not seeing this audit in either pass/fail group.

[patrickhulce]

@rviscomi it's been living in the full-config for basically its entire life so you can only get it by using the CLI and manually passing in --config-path=./lighthouse-core/config/full-config.js

blocking item to move it into default is gathering data on how much of an impact turning on those debugger domains has on performance measurement

[rviscomi]

Ahh ok. Is there an issue I can watch for the perf measurements?