Log CWV events to the console

[rviscomi]

Is your feature request related to a problem? Please describe.
The CWV values reported by the extension are useful snapshots of the UX, but they don't necessarily have any diagnostic information for developers to understand what could have caused adverse experiences.

Describe the solution you'd like
I'd like to see the extension utilize console logging more to leave an audit trail to assist developers with debugging CWV issues. For example, log the times at which CLS changes and if possible attribute each shift to the culprit element. Or for LCP, log the elements that are considered the largest and the times at which they are painted. For FID, it'd be helpful to know the timestamp of the first input and what was clicked.

The extension can be a first class developer tool for not only understanding how pages are experienced but also debugging how to make them better. Stretch goal: maybe like a VisBug for performance?

[gilbertococchi]

Hi @rviscomi and @addyosmani I've opened a PR with a proposed Console Logging option here: #80

[rviscomi]

Comment from the related PR:

Maybe we can support different logging levels, such as debug (metric name + value) and verbose (metric name, value, metric object with all the entries).
WDYT?

I think the way you have it here is a good first step for this PR and we can keep #77 open to revisit it with enhancements like the one you suggested.

[rviscomi]

Leaving this open to continue exploring the logging levels feature described in the previous comment.

[tunetheweb]

So #115 introduced a summary table of key info, as well as the full, detailed, Performance Observer entries, with extension options to have one or the other or both.

Rick's suggestion is to link these to the console log levels:

Perhaps tables as Info (since console.table only logs at Info level anyway) and PO entries as Verbose.

[tunetheweb]

Thinking about this some more I'm not 100% sure using the DevTools levels are are better way of going compared to turning it off an on in the extension options. I do wonder if we should leave those levels for the developer to manage in their own apps and it if might be more confusing to enable something and not see it if they have verbose turned on/off by default.