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.
What this means
Core Web Vitals are a set of field performance metrics: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness, which replaced First Input Delay), and Cumulative Layout Shift (visual stability). Lab tools like Lighthouse estimate them, but field data from real visits is the ground truth — and that is what you can stream into analytics as events.
Modelling them as events
Google's web-vitals library exposes onLCP, onINP, and onCLS callbacks that fire with a metric object containing a name, value, rating, and a unique id. A common pattern is to send each as a GA4 event (often named after the metric) with the value and a non-identifying page path. The id lets you deduplicate a metric that updates during a session. Keep parameters generic: metric name, value, rating, path — nothing about the person.
- LCP (loading), INP (responsiveness), CLS (stability)
- web-vitals library reports name, value, rating, id
- Send value + path; no visitor identity
How it appears in analytics and logs
A web-vitals event carries a metric name and value from a real session. High LCP or INP on a template means real users experience slowness that lab tests may miss.
Diagnostic use case
Send LCP, INP, and CLS from real visits as custom GA4 events so you can monitor field performance per page and device without identifying anyone.
What WebmasterID can help detect
WebmasterID can record performance signals as first-party events, so field Web Vitals sit alongside engagement data without cookies or cross-site identity.
Common mistakes
- Sending lab scores instead of real field measurements.
- Forgetting INP replaced First Input Delay as a Core Web Vital.
- Attaching visitor identifiers to a performance event.
Privacy and accuracy notes
Web Vitals values are timings and layout-shift scores, not identities. Send the metric name, value, and a page path — never anything that identifies the visitor. This is educational, not legal advice.
Related pages
- Page timing and Navigation Timing events
Page timing events record how long parts of a page load took — DNS, connection, time to first byte, DOM content loaded, and full load. The browser's Navigation Timing API exposes these durations precisely, and you can send them as analytics events to monitor real-world speed. They are pure timings, so they are among the safest events to collect, carrying no information about who the visitor is.
- Timing and performance events
Universal Analytics had a dedicated user-timing (timing_complete) feature. GA4 has no direct equivalent, so site-speed and timing measurement is done with custom events carrying numeric parameters, often sourced from the browser's Performance APIs and Core Web Vitals. This page explains how to measure timing in GA4 without inventing benchmarks, and how Web Vitals map onto custom events.
- Custom events: tracking what matters to you
Custom events capture meaningful actions a pageview cannot — a CTA click, a signup, a video play, a form submit. The value is in a consistent naming taxonomy and well-chosen properties. The risk is putting personal data into event names or properties, which turns analytics into surveillance. This page covers both.
- Website observability
Field performance as first-party events.
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.