1. If we associate a nodeId with FCP, it would always be the same node as LCP. Look at the algo again: first, Chromium looks at each paint and determines whether it’s FCP/LCP. Then, it uses ImagePaintTimingDetector and TextPaintTimingDetector to determine what image or text rendered within that paint. And then, it associates that image or text with LCP.
   If we were to implement node detection for FCP, we’d use the same ImagePaintTimingDetector and TextPaintTimingDetector. And for the same paint, they would always return the same nodeIds.

I feel like I'm getting tripped up on this point. Having the same timestamp seems necessary but not sufficient, because many nodes can have very different critical paths but still be presented at the same time (since all the paint timing trace events set their ts to the paint time).

For example, a page with text included inline in the html document as the typical FCP but an LCP image requiring a fetch. Depending on the machine, the connection, and the rest of the page (e.g. render-blocking resources, if the LCP image is identifiable by the preload scanner, etc), the LCP image might be ready to paint in the same frame as the text. On a slower device and connection, though, the LCP image might not be ready by the time the browser can make that first contentful paint.

Am I missing something, though?

I do agree it will be difficult to impossible to annotate the FCP trace event with the node that was painted since flagging contentful paints is done in so many places, and they all only record the timestamp for use in PaintTiming::MarkPaintTimingInternal because that's all that's ever been needed. There are some other layout and painting trace events with somewhat extensive node info recorded, but it would likely be a lot of work and still not enough to establish equivalence. The effort to only evaluate nodes for timing/tracing on frames means this aliasing might be a fundamental problem for simulated throttling regardless, and that improvements will have to come entirely from the simulation side.

Brendan describes the following scenario:

• You have a page like this:

  <link rel="stylesheet" href="/tiny-stylesheet.css">
  <p>Hello!</p>
  <img src="/1mb-image.png">

• On an unthrottled connection, both the stylesheet and the image take 200 ms to download (because the bottleneck is latency). The stylesheet is render-blocking, so it delays FCP by these 200 ms. When the stylesheet is downloaded, FCP happens with both text and image already rendered. Because the image is the largest page element, LCP also happens at the same paint timestamp as FCP.
• On a throttled connection, the stylesheet takes 200 ms to download, but the image takes 1s. When FCP happens, only the text is visible. LCP happens 800 ms later.

This is a trivial example that breaks the heuristic implemented in this PR. The code here will see that unthrottled LCP is equal to FCP, and it will simulate the throttled LCP as also being equal to FCP, even though that’s not right.

The other issue (as I realized earlier) is that comparing node IDs is useless.

For LCP, there’s a clear way to link it to a node ID: look at the paint → find the biggest text or image node → take its id. That’s what Chrome does.

But how do you do it for FCP?

• Do you look at the FCP paint and also find the biggest text or image node? This is useless: whenever FCP and LCP would happen during the same paint, the biggest node in that paint will always be the same! As a result, if you check fcp.paintId === lcp.paintId¹ && fcp.nodeId === lcp.nodeId, the second condition will always be true when the first one is true, making it unnecessary
• Or do you look at the FCP paint and find the first text or image node? This is misleading: the first text or image isn’t necessarily the largest, so you’ll have false negatives.
• Or do you collect all node IDs rendered during FCP? But why also useless: if FCP and LCP happened within the same paint, it’s guaranteed the LCP element will be among FCP elements. So if you check fcp.paintId === lcp.paintId¹ && fcp.nodeIds.includes(lcp.nodeId), the second condition will also always be true when the first one is true

So, adding the fcp.nodeId === lcp.nodeId check doesn’t help in any way.

¹ — or, in practice, fcp.timestamp === lcp.timestamp, as this PR does. The timestamp has a microsecond precision (afair), so if two timestamps match, we can assume that was the same paint ID.