-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🔊[RUM-2324] Telemetry on other wrong LCP cases #2531
Conversation
/to-staging |
🚂 Branch Integration: starting soon, merge in < 3s Commit c1c27add40 will soon be integrated into staging-50. This build is going to start soon! (estimated merge in less than 3s) you can cancel this operation by commenting your pull request with |
🚂 Branch Integration: This commit was successfully integrated Commit c1c27add40 has been merged into staging-50 in merge commit cdc81f9e5d. Check out the triggered pipeline on Gitlab 🦊 |
/to-staging |
🚂 Branch Integration: starting soon, merge in < 0s Commit c1c27add40 will soon be integrated into staging-51. This build is going to start soon! (estimated merge in less than 0s) you can cancel this operation by commenting your pull request with |
🚂 Branch Integration: This commit was successfully integrated Commit c1c27add40 has been merged into staging-51 in merge commit 1ccefed72d. Check out the triggered pipeline on Gitlab 🦊 |
Motivation
Following #2515, some LCP data seemed wrong for other reasons than startTime = 0.
Changes
LCP with startTime < previous LCP
LCP with size < previous LCP
visibilityState
: always visibleprerendering
: always falsenavigationStart
: from one case, the value did not really make sense (~30s after timeOrigin) but not sure how reliable it is supposed to be anyway.lcpEntries
to the debug data, to double check if the implementation difference with google may have an impactTesting
I have gone over the contributing documentation.