CLS delay in realtime and other CWV questions
Common questions about Core Web Vitals metrics, focused on why CLS behaves differently from other vitals in realtime reporting.
Why does CLS take up to 10 minutes to stabilize in realtime?
Section titled “Why does CLS take up to 10 minutes to stabilize in realtime?”CLS measures visual stability across the entire lifespan of a page, not just the initial load. It accounts for async resource loading, dynamic DOM elements, scroll-bound animations, lazy loading, and any other event that shifts layout while a user is on the page.
This full-lifespan measurement is what creates the delay. Marfeel tracks user presence every few seconds and sends data back to the ingestion system via unload beacons. The browser’s unload beacon implementation does not systematically trigger them. When a user locks their phone instead of closing the tab, for example, no beacon fires.
For these unterminated sessions, Marfeel’s ingestion system waits approximately 10 minutes before considering the session complete. CLS is computed only after the page lifecycle can be considered terminated. That 10-minute window is the time the system needs to close abandoned sessions (when no presence event or unload beacon has triggered) and to calculate CLS properly.
Why is this delay only visible on CLS?
Section titled “Why is this delay only visible on CLS?”Most Core Web Vitals, including LCP, TTFB, and FID, are not user-interaction-based. Their measurement is deterministic and consolidates almost instantly.
INP also depends on user interaction, but its value is captured per event rather than across the full page lifespan. CLS is unique because it accumulates layout shift scores over the entire session, so it cannot be finalized until the session ends.
Why does it only affect some domains?
Section titled “Why does it only affect some domains?”Websites that feature interactions causing layout shifts during navigation see greater CLS fluctuation in realtime. If a site has scroll-bound animations, dynamically injected ads, or late-loading elements, CLS values remain unstable until the system confirms the page session is over.
On sites with minimal dynamic content, CLS stabilizes quickly because fewer late-firing layout shifts occur during the page lifespan. The CLS Offenders view can help identify which specific elements are responsible for these shifts.
Why does CLS take up to 10 minutes to stabilize in realtime?
CLS measures visual stability across the entire lifespan of a page. Marfeel tracks user presence every few seconds and relies on unload beacons to close sessions, but browsers do not always fire these beacons. For unterminated sessions, such as when a user locks their phone, the ingestion system waits approximately 10 minutes before considering the session complete. CLS is computed only after the page lifecycle is terminated, which creates the delay.
Why is the CLS delay not visible on other Core Web Vitals?
Metrics like LCP, TTFB, and FID are not user-interaction-based, so their measurement is deterministic and consolidates almost instantly. INP also depends on user interaction, but its value is captured per event rather than across the full page lifespan, so it does not exhibit the same delay as CLS.
Why does the CLS delay only affect some domains?
Domains that feature interactions causing layout shifts during navigation experience greater CLS fluctuation. On sites with minimal dynamic content or scroll-bound animations, CLS stabilizes quickly because fewer late-firing layout shifts occur during the page lifespan.