Problem/Motivation
Largest Contentful Paint isn't a single event in a page load, chrome first multiple 'largest contentful paint candidate' events - i.e. whatever the biggest most recent paint event was gets a new event, but because potentially the page could continue rendering at any moment, and add another, bigger, contentful paint, it doesn't report an actual LCP metric as such.
There are JavaScript libraries that do report a single LCP metric, but they have to be added to the page itself, this is good for production telemetry but it's less clean for lab testing which is what we're trying to do.
The current code in PerformanceTestBase hard codes a maximum of two LCP events (because that's the maximum in Umami at the moment), and a maximum of 30 seconds, and polls for them until it reaches either one, then gives up.
Probably we can do better than this, but it was the best I came up with. This was not helped by https://bugs.chromium.org/p/chromium/issues/detail?id=1463436 which took days (over a period of weeks) to track down and workaround too.
Steps to reproduce
Proposed resolution
One possible idea would be to allow the test itself to add an 'expected number of LCP events' when it's recording telemetry spans - so for some pages this might be one, for some two, for some three. Then for pages with one LCP event, we wouldn't need to wait for 2 or 30 seconds but would be done as soon as we get it.
We could even add an assertion on this - not on how long they take, but on how many there are. However this requires them being 100% reliable so we don't get false negatives/random test failures. I'd like to see the whole system running on commits before trying to adding the assertion so we can confirm it's reliable over time on gitlab's infra.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet