core(lantern): compute LCP as FCP when they occur within the same frame

[iamakulov]

Summary

This PR implements the first change discussed in #16539. When real-world FCP and LCP are the same, we assume they originated from the same element (that’s roughly how it works inside Chromium), and we make the simulated LCP also equal the simulated FCP.

This leads to some sites getting better (and hopefully fairer) scores. How many sites are affected, and how better are the scores? See https://observablehq.com/d/f62cde3eb2ec3e76 for a study across ~350 sites.

Related Issues/PRs

#16539

[iamakulov]

I tried my best to measure the impact across the board, but I ran into one Lighthouse peculiarity that I couldn’t overcome. From the link above:

Can we trust this data?

Yes and no. I did my best collecting the data over a wide range of sites in a stable environment (t3.large), and filtering out sites that might be problematic (have warnings, etc). However, there’s still one peculiarity in Lighthouse traces that I can’t get rid of.

When you run a Lighthouse test from the Lighthouse CLI (as opposed to DevTools), the first paint often end up significantly delayed. For example, here is one site from the dataset (https://platepost.io/wywhcoffee):

DevTools Lighthouse	CLI Lighthouse
(Trace)	(Trace)

Despite the site being the same, and the page being renderable after HTML/CSS loads, with CLI Lighthouse, the first paint would often happen 500-1000ms later than I’d expect it to. This happens both with a “cold” browser (a browser that’s re-launched for every Lighthouse test; the default Lighthouse behavior), and with a “warm” one (a single Chrome instance shared among all Lighthouse tests).

This likely skews the test results, making simulated FCP/LCP worse.

Would appreciate some tips if you know what’s causing this / how to solve this! (Pre-warming the browser where you open it ahead of time and load google.com doesn’t seem to help.)

Ah, and, yes, let me know what the next best steps are / how I can help to get this merged :)