GoogleChrome / GoogleChrome/web-vitals
Firefox sometimes reports the wrong LCP element
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 8.6k
- Forks
- 531
- Avg merge
- 3h 4m
- Merged PRs (30d)
- 3
Description
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
- Our 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
assertsfor 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
pelement (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
h1element (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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with src/lib/bindReporter.ts, src/onLCP.ts, and test/e2e/onLCP-test.js to understand the Firefox-specific assumptions described here. Check the linked Firefox and specification issues before changing anything; done means Firefox has aligned its behavior and the lesser test-suite workarounds can be revisited without breaking the existing LCP assertions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- performance
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100