-
Notifications
You must be signed in to change notification settings - Fork 391
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
LCP and CLS report callback are significantly delayed #405
Comments
This is working as intended. Both LCP and CLS (and also INP btw) can change throughout the life of the page (1). For example a larger element could still be inserted into the page at any time and become the LCP element and time. Therefore it is not possible to know when the value we have is the "final" value of this metric and since you are not using This differs to TTFB (which can be finalised and reported as soon as the first bytes are received as it will not change after that), FCP (similarly as soon as first contentful paint happens) and FID (when first interaction happens). (1) Note for LCP it can be finalised on interaction:
In these case it is reported earlier: Lines 99 to 107 in 16e6e93
(2) Other than the above case for LCP when an interaction happens, LCP, CLS, and INP should really only be reported when the user navigates away from the page. The web-vitals.js library does do this, but also reports on other other case, which is when the page visibility changes (i.e. the tab is backgrounded). We do this because there this is the last reliable time to report for a page in certain circumstances (e.g. if the page is never foregrounded again), though this can also lead to duplicate reporting (e.g. if the CLS is reported on backgrounding, the page is foregrounded again, has some more CLS for example, and then you leave, then you will get two CLS reports), but it's the best we can do (FYI, the Chrome team are working on a new API for circumstances like this to only report this once!). You can see LCP stops listening with the Line 109 in 16e6e93
CLS reports (but then continues listening): Lines 113 to 116 in 16e6e93
and INP does similar: Lines 227 to 238 in 16e6e93
LCP has an additional check that ignores pages that were opened in the background (as measuring LCP in this case is tricky, as technically the paint doesn't happen until the user foregrounds the tab but that might be way after the LCP content has actually loaded). But that is unrelated to late reporting (it never reports in this case). So all in all it is expected to report LCP, CLS, and INP much later. |
Yes, but at some point the value has to be "final". I can have
You cannot know its the final LCP unless the lifecycle of the page is over (like on unload). Otherwise its just an arbitrary point in time when it says "i guess page won't change now". So it being reported at 40 seconds right now is a bug! Should not report till I navigate away or interact.
Yes, I saw this in the implementation but when recording field metrics, it is not great to rely on user interaction to report. If they open the page, then close it in 5 secs, the metric is lost. We are not blocking unload till the reporting call is successful (which would be bad anyway). Also for websites that are not Single Page Apps, clicking on any content can mean navigating away and lost metrics.
I think having a Tl;dr: (1) What do you think of |
There is no 40 second timeout. You must have backgrounded the tab at the 40 second mark. That is also why CLS was reported at the same time. It also seems somewhat contradictory that you are complaining about a max timeout (that does not exist) but then asking for a user-defined max timeout.
As discussed above the web-vitals library reports metrics on visibility change (including page unload), or sooner if they can be finalised sooner. It is not arbitrary.
No, if they open the page and then close it after 5 seconds, the page visibility will change, and there the beacons will fire. The page will hold navigating away until the event fires. Pages do block navigating on event handlers firing, otherwise there would be no point in having event handlers for these.
If it happened like that without backgrounding the page that would certainly be a bug, but I don't believe it does. Please provide a site where that happens.
This has been discussed before (for example in #394), but the point of the web-vitals.js library is as detailed in the home page of this project:
So we are against adding such an option because we believe the current methodology are the most accurate ways of measuring the Web Vitals. |
This is possible, if I can repro it reporting, I will file an issue.
Yeah not sure why I saw it reported at round 40 secs, but I am mainly asking for a timeout.
Yes, the unloading JS will run, but I am not sure if there is a guarantee of network calls for reporting being fired successfully (with 200 OK response; I think HTTP/2 server would close connection if the client fires request but connection is closed/lost before 200 OK?). There are other issues, for example on mobile, bad connection/network when closing it, etc. Like in the metro/tube, you might lose network and close the page.
Thanks, I will maybe use |
Yes, there are definitely cases where beacons can be lost, and this only increases with late beacons. However, that must also be weighed against the cases that beaconing early reports incorrect data. The library currently chooses to choose correctness over more beaconing.
Do read my comments here: #394 (comment). Will close this for now, but let me know if you have any more questions. |
According to the README:
Currently, I see FCP and TTFB being reported immediately when page is loaded, but LCP and CLS are significantly delayed (page is not loaded in background and callback is fired, but its too late). FYI: I am not using
reportAllChanges
.My network timeline:
FCP and TTFB happen at 6.8 secs which is reasonable:
LCP and CLS are at 43 seconds!! Users don't stay on a page that long!
Is this a bug? If I setup a
PerformanceObserver
withtype: "layout-shift"
, the callback happens instantly. Looking at the code, I see it tracks "session" in the 5 sec window or creates a new session, etc. But that should not take 40 secs to report. LCP is also delayed and it just checksvisibilityWatcher.firstHiddenTime
which should beInfinity
as the window is always visible in this case.The text was updated successfully, but these errors were encountered: