Doing some local testing and noticed the console logs that print a table-view do not use [Web Vitals Extension] prefix.

I don't know if there is a clean way to do that using console.table command, but, perhaps you could use console.group('[Web Vitals Extension]') and console.groupEnd() to wrap the table?

Already added a few commits ago. Download the latest version!

I went with adding it to the end of the column name (so sometimes elided if your dev tools is small but that's OK as still works for filtering)

LGTM, I really liked the Table view for both LCP, CLS and INP breakdowns. Thanks for reducing the digits a bit on CLS and adding the "[Web Vitals Extension]" label in the Table.

(I'm using the latest, but it was elided because it was too small.)

Actually, playing with console.groupCollapsed api gives me an idea... what if we just merged all the console options, with something like this:

console.groupCollapsed('[Web Vitals Extension] INP 200.0', entry);
console.table([{a:1,b:2},{a:3,b:4}]);
console.groupEnd()

By default it looks just like a single line:

(It supports showing objects, too, which I did not expect)

But if you expand you see the full table:

This sorta hides table breakdowns by default, so if we hear that folks really want them expanded by default then the Option in settings can turn into:

"Show metric breakdowns by default" or something like that?

Also, I'm not sure I understand what CLS is trying to show?

Why are there several reported shifts with the same score each?

(Barry: Im working on a small patch to try to console.group changes, will send over)

One more thing, once I tried to open the setting page and it just stalled on me. I noticed I have errors in the extension page and one is related to manifest permissions and the options page:

...wonder if its related to manifest v3, but, I can open the options page most of the time fine, so no idea...

...it just happened again. I am not sure, but it may depend on the specific tab/page I have opened when I select the options menu item. I don't see why it should matter, but maybe the handler for the extension contextmenu is trying to access the current page?

Also, I'm not sure I understand what CLS is trying to show?

Why are there several reported shifts with the same score each?

We only get a shift score per set of shifts. For example if you add a banner image, and it shifts three images down then that's one shift, one shift score, and three elements affected. It would be SOOO much nicer if we got the element causing the shift rather than the victims :-(

Makes a bit more sense when there's two sets of shifts:

An alternative would be this, but don't like it myself:

WDYT?

TBH I think we need to pare down the scope of this PR to unblock the P0 changes and focus on #110 and #112. The work on non-LCP tables doesn't feel fully baked yet, so I think it'd be worth speccing that out in an issue first.

That seems fine to leave as-is and to follow-up as needed.

(FWIW even for CLS there is an advantage in just copying things into the table: if the nodes that shift disappear from DOM the attribution disappears from the console.logs... but if you copy it to a table right as the entries are fired, those copies will stay. It actually helped me a second ago already.)

In other words, +1 to land tables as they are an iterate afterwards.

One more thing, once I tried to open the setting page and it just stalled on me. I noticed I have errors in the extension page and one is related to manifest permissions and the options page:

Extensions cannot access chrome:// or chrome-extension:// URLs for security reasons so you see this error when you load that page.

The same thing happens with the production version except you don't get a nice Error screen and instead have to use Inspect Views to see this:

We could add these URLs to the manifest to avoid this error. But this is more a knock on from #104 rather than this PR.

And it's more obvious as there is an Error screen for local development and you're looking at it a lot.

Raised #118 for that issue but, as I say, nothing to do with this PR (nor #104 as it turns out as this was also an issue with Manifests v2).

I played around with console.groupCollapsed but didn't like it myself. Found it confusing with so many collapsed bits (especially including the object).

I think we want this to be the super simple "easy" path for people wanting a bit more details than the HUD gives, but that don't want to hunt around in the Performance Observer entry that they currently have.

I agree that groupCollapsed works odd with entries which are themselves collapsed. I think we can postpone that work to a separate PR... but... here is what I did in a local branch:

Collapsed:

Expanded:

I think for live tracing (e.g. for INP) where we show EVERY event doing it collapsed makes sense. But I was seeing that as a separate option for future.

I was seeing these tables as more of a summary view for (ideally only one per metric). Because of the way web-vitals.js works we may see a few more (e.g. an initial LCP and then another LCP) but hopefully not so many that collapsing would be necessary.

But agree people should switch this view off when looking at the future live trace view.

Agreed with Michal to merge as is an iterate if needs be.