muuuuuch better :) thanks!

I think there's an edge case this may not account for.

The situation would be theverge loading in one tab while nytimes is loading in another tab. keyEvents is for all processes and so I think the resulting LCP-AF would merge together both tabs.

I'm not sure this is the case, but it looks like it...

the trace event lives in browser/ so my guess is it's emitted on the browser process. it does contain a mainframeid however. and we have findMainFrameIds, so I think we can filter the trace events to be just the mainframeid ones we care about.

The situation would be theverge loading in one tab while nytimes is loading in another tab. keyEvents is for all processes and so I think the resulting LCP-AF would merge together both tabs.

I jumped to this as well, but I tried on half a dozen pages unsuccessfully 😅 Is the "looks like it" from looking at the code in Chromium or a case that you observed?

What would a trace like this look like?

Using the performance panel, I am able to produce a trace with LCP-AF events with two different values for main_frame_tree_node_id.

hmm i just got one.

trace: https://gist.github.com/paulirish/ebfeeac8d2a243042041ab4e1bc87c7f

repro:

• chrome-debug
• open devtools
• open another chrome window, and make sure both windows are visible (not occluding the other)
• put example.com in window 1's omnibox and paulirish.com in window 2's.
• start perf panel recording
• hit enter on both omniboxes
• wait a bit and stop recording

and make sure both windows are visible (not occluding the other)

🤦 this is almost definitely what I forgot

@paulirish findMainFrameIds doesn't return a node id, is there another way to get the main frame node id?

@paulirish findMainFrameIds doesn't return a node id, is there another way to get the main frame node id?

good question.... doing this would certainly be easier if main_frame_tree_node_id was instead main_frame_tree_frame_id but alas. Hmmmm.. we'll have to do some hunting.

@npm1 do you currently make use of main_frame_tree_frame_id to filter things? as of now, we don't have any mapping between frames/frametrees to node ids, so before we invent one, I'm curious if something already exists.

something i spotted while looking at the trace event.....

https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/page_load_metrics/observers/core/ukm_page_load_metrics_observer.cc;l=1091-1095;drc=2b934611e4e480b7121488288f97ef27e0950e2a

It seems like sometimes the trace event carries a specific timestamp.. so i think we'd want to use that rather than the event's ts.

I can't seem to find the timestamp you're referring to. There is only a durationInMilliseconds property.

my silly project agrees with @adamraine https://github.com/connorjclark/chrome-trace-events-tsc/blob/master/dist/lh-trace-events.d.ts#L487 (altho I only used one recent trace from cnn.com)

@connorjclark thanks for checking. yeah you can see in the .cc source i linked that there are two ways the LCP trace event are emitted. I haven't really tracked back the conditions that determine which of the two are used.. but.. we'd need enough traces to get both of em for yr project to catch it, i guess. no big deal though.

@adamraine ah yeah.. actually the durationInMilliseconds prop is exactly what i was talking about. (I hadn't clicked through on DataAsTraceValue() till now).

But yes it looks vaguely like: if durationInMilliseconds is being provided, it should be used rather than the ts of the event. @npm1 is that what's going on?

if durationInMilliseconds is being provided, it should be used rather than the ts of the event.

👀 at our time origin complexities, oh boy 😅

Correct, durationInMilliseconds is the LCP value. Sorry for the confusion, maybe there was a way to have the trace event's timestamp be the LCP itself? It's probably a bit late to fix.