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.
How LCP is captured
LCP comes from the PerformanceObserver API observing the 'largest-contentful-paint' entry type; the final value is the last such entry before the first user interaction (web.dev). The web-vitals library wraps this and reports a stable LCP. You then send that number as an event parameter — for example event 'lcp' with a value field — alongside the page identifier.
Reading field LCP
Lab LCP (from a single synthetic run) and field LCP (from real users) differ; field data captures the variety of real devices and networks. Aggregating field LCP by page template shows which layouts are slow to paint their main element. Do not publish a fixed 'good' number here as fact — refer to current Web Vitals guidance for thresholds, which can change.
- Capture via PerformanceObserver 'largest-contentful-paint'
- Send the value as an event parameter
- Field LCP reflects real devices; lab LCP does not
How it appears in analytics and logs
High LCP values on a template point to slow loading of its main element — often an image or hero block — affecting perceived speed and user experience.
Diagnostic use case
Track real-user LCP per page or template by observing the largest-contentful-paint entry and sending its value as an event parameter for segmentation.
What WebmasterID can help detect
WebmasterID can record field LCP as a first-party performance event keyed to a page or template, with no cookies and no per-visitor identity.
Common mistakes
- Reporting only lab LCP and ignoring field variation.
- Attaching user identifiers to a page-level timing.
- Hard-coding a threshold as if it were permanent.
Privacy and accuracy notes
LCP is a timing number tied to a page, not a person. Send the value and page context only; never attach identifiers to make it a per-user profile.
Related pages
- 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.
- 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
Record real-user LCP per page, 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.