Firefox sometimes reports the wrong LCP element

[tunetheweb]

So Firefox has a bug and can (and frequently does) report multiple LCPs for a single frame: https://bugzilla.mozilla.org/show_bug.cgi?id=1977827). Technically this may have been per spec but we've agreed to change the spec.

In the meantime, this looks like this for example:

startTime	Element	size
500	p	1000
500	h1	2000

So two different elements with the exact same render time, but different sizes.

This causes a few problem with this library:

• We avoid reporting if there is no move in the metric
• This is also explicitly noted in the README
• Out LCP test suite makes several assumptions here and frequently checks both the delta and the correct element is reported in the emitted LCP callback. These assumptions do not hold true for Firefox which is why I've commented out a couple of those asserts for Firefox now now.

The net effect of this is we can see the following (if they are emitted as two entries and processed separately):

• See the first LCP event and process it.
• See the second LCP event and ignore it.
• The LCP is then reported as 500 (which is correct), with attribution saying this is for p element (which is incorrect).

Alternatively, if they are emitted in the same callback, we may just take the last entry and so see it reported like this:

• See the multiple LCP events and only process the last one
• The LCP is then reported as 500 (which is correct), with attribution saying this is for h1 element (which is also correct).

We could change this to address the first case, by processing each event regardless and update if the time, or size, changes but this would be a breaking change IMHO. It would also require quite a few changes to the test suite to handle this. The fact that our test suite broke so badly when I tried this, based on assumptions this would not happen, and that this assumption was baked into this library concerns me that correcting this would cause breakage to users of the library too

Given we've resolved to change Firefox's behaviour I've decided to leave this as is. The library will report the wrong element for Firefox on occasion. I'm leaving this issue open as a warning (and a reminder to clean up the lesser workarounds in the LCP test suite) when Firefox lands the changes to bring this into line with the other browsers.

[Mimori256]

it might be worth adding a brief note in the README’s Limitations section mentioning that LCP attribution can be best-effort in rare browser-specific edge cases (e.g., a current Firefox behavior expected to be resolved in future versions) I suppose

[tunetheweb]

I think that's a given to be honest. We have similar issues when the LCP element is removed before the performance observer fires.

But the point of me opening this issue was to have somewhere to point people to in case they asked.

Hopefully will be resolved soon, so I don't think it's worth adding to the README. Will revisit if lots of people start noticing and complaining.

[Mimori256]

Makes sense, thanks for the explanation!
Good to have this documented in the issue for reference.