You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Lighthouse sometimes stops collecting data before the page has finished loading. As a result some requests/user timing metrics/CPU times are not included in the report, or are only included intermittently.
(We talked about this before, but I wanted to document it since it keeps coming up. Not sure if it's something that can be fixed, might just build a custom solution.)
Why does it happen?
Lighthouse waits until the page is interactive, based on the TTI definition:
no more than 2 requests in progress for a certain amount of time (0s for simulated throttling, 5s otherwise)
CPU idle for a certain amount of time
Sometimes that's different from when a user would say that the page has finished loading. If a page only renders after a slow Ajax request has finished, Lighthouse stops collecting data before the main page content has loaded.
This is often a problem with apps, where the most of the action only happens after a JavaScript bundle or JSON response has loaded.
I'm also seeing this occasionally when there's a chat widget on the page, sometimes it will be counted in the Lighthouse metrics, other times Lighthouse stops waiting before it's loaded.
Possible solutions
1. Add a --waitForExpression option that forces Lighthouse to wait for a DOM element or user timing
Easy to implement, but means users have to opt in and identify a condition that makes sense for their site.
2. Allow the site to emit an event indicating it has finished loading
@patrickhulce mentioned there was a proposal at some point to let sites emit an event that indicates the page has finished loading.
This might make it easy for sites to game metrics. Needs work by website owners.
3. Use smarter logic to decide that the page has finished loading
For example, this could mean waiting for no requests to be in progress. (@paulirish brought up waiting only for non-media requests, or only waiting for requests with a priority higher than medium.)
Maybe we could only wait for requests that are still sending data, not requests that are long polling or just timing out?
Interactive vs finished loading
Most users would assume they are the same thing, and for most sites they are. But by definition TTI will be at the point where the page is idle for a while, even if the main content is still loading.
If we keep collecting data after the page is interactive we'd be might be reporting 25s of JS execution but a TTI of 4s. This could be confusing for users who don't understand the difference to "finished loading".
Related issue: waiting for too long
When several requests are timing out Lighthouse will wait a long time for all of them, even if the page is otherwise completely idle.
The text was updated successfully, but these errors were encountered:
mattzeunert
changed the title
Wait for page to be fully loaded
Wait for page to finish loading
Apr 16, 2020
Lighthouse sometimes stops collecting data before the page has finished loading. As a result some requests/user timing metrics/CPU times are not included in the report, or are only included intermittently.
(We talked about this before, but I wanted to document it since it keeps coming up. Not sure if it's something that can be fixed, might just build a custom solution.)
Why does it happen?
Lighthouse waits until the page is interactive, based on the TTI definition:
Sometimes that's different from when a user would say that the page has finished loading. If a page only renders after a slow Ajax request has finished, Lighthouse stops collecting data before the main page content has loaded.
This is often a problem with apps, where the most of the action only happens after a JavaScript bundle or JSON response has loaded.
I'm also seeing this occasionally when there's a chat widget on the page, sometimes it will be counted in the Lighthouse metrics, other times Lighthouse stops waiting before it's loaded.
Possible solutions
1. Add a
--waitForExpression
option that forces Lighthouse to wait for a DOM element or user timingEasy to implement, but means users have to opt in and identify a condition that makes sense for their site.
2. Allow the site to emit an event indicating it has finished loading
Suggested here: #3748
@patrickhulce mentioned there was a proposal at some point to let sites emit an event that indicates the page has finished loading.
This might make it easy for sites to game metrics. Needs work by website owners.
3. Use smarter logic to decide that the page has finished loading
For example, this could mean waiting for no requests to be in progress. (@paulirish brought up waiting only for non-media requests, or only waiting for requests with a priority higher than medium.)
Maybe we could only wait for requests that are still sending data, not requests that are long polling or just timing out?
Interactive vs finished loading
Most users would assume they are the same thing, and for most sites they are. But by definition TTI will be at the point where the page is idle for a while, even if the main content is still loading.
If we keep collecting data after the page is interactive we'd be might be reporting 25s of JS execution but a TTI of 4s. This could be confusing for users who don't understand the difference to "finished loading".
Related issue: waiting for too long
When several requests are timing out Lighthouse will wait a long time for all of them, even if the page is otherwise completely idle.
The text was updated successfully, but these errors were encountered: