Sending CLS as an event
Cumulative Layout Shift (CLS) is a Core Web Vitals metric for visual stability: the sum of unexpected layout-shift scores during the page's life, bucketed into session windows. You capture it from the layout-shift PerformanceObserver entries (or web-vitals) and send it as an event with the score as a parameter. It is a genuine UX signal, defined by a documented formula, that you report under your own event name.
How CLS is computed
Each unexpected shift has a layout-shift score = impact fraction × distance fraction; CLS is the largest sum of scores within a session window of shifts (web.dev). The PerformanceObserver 'layout-shift' entry type yields the inputs, and web-vitals implements the windowing. You send the resulting score as an event parameter, for example event 'cls' with a value field.
Reading the score
Lower CLS means a more stable layout. Aggregating by template reveals which pages shift the most — often from images, embeds, or ads inserted without reserved dimensions. Use field CLS to prioritise reserving space for dynamic content. As with other Web Vitals, treat published thresholds as current guidance that can be revised, not as a permanent constant to assert here.
- score = impact fraction × distance fraction, summed per window
- Capture via 'layout-shift' PerformanceObserver entries
- Aggregate field CLS by template to find unstable layouts
How it appears in analytics and logs
A high CLS on a template means content moves unexpectedly as it loads — usually images or ads without reserved space — which frustrates users mid-interaction.
Diagnostic use case
Track per-template visual stability by capturing layout-shift entries, computing CLS, and sending the score as an event parameter for comparison across pages.
What WebmasterID can help detect
WebmasterID can record field CLS as a first-party performance event tied to a page or template, with no per-visitor identity and no cookies.
Common mistakes
- Counting user-initiated shifts as unexpected ones.
- Reporting a single lab CLS as if it were field-representative.
- Stating a fixed threshold as a permanent fact.
Privacy and accuracy notes
CLS is a per-page stability score, not a person. Report the score and page context only; do not attach identifiers to build a per-user profile.
Related pages
- Sending LCP as an event
Largest Contentful Paint (LCP) is a Core Web Vitals metric for perceived load speed: the render time of the largest content element in the viewport. To analyse it per page you capture LCP via PerformanceObserver (or the web-vitals library) and send it as an event with the value as a parameter. It is a real performance signal, not a GA4-named event, so the event name and parameter are yours to define.
- Sending INP as an event
Interaction to Next Paint (INP) is a Core Web Vitals metric for responsiveness: it reflects the latency of interactions across the page's life, reporting a representative worst interaction. You capture it from the Event Timing API (or web-vitals) and send it as an event with the value as a parameter. INP replaced First Input Delay as the responsiveness Web Vital; it is a documented signal you report under your own event name.
- Tracking Core Web Vitals as events
Core Web Vitals — Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift — are field performance metrics you can record as analytics events. Google's open-source web-vitals JavaScript library measures them in real browsers and hands you a value and an id you can send as a custom GA4 event. This page covers what each metric means and how to model it as an event without any personal data.
- Website observability
Track visual stability per template, first-party.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.