A RUM script observes 'largest-contentful-paint' and 'event' entries in the browser and POSTs each entry to an analytics endpoint as it arrives. Why does that produce wrong Core Web Vitals numbers, and what is the correct collection pattern?

## Entries are observations; metrics are reductions The mistake is treating the performance timeline as an event stream of finished measurements. It is not. Each entry type reports raw observations, and each metric is a *reduction over* those observations that only becomes final when the page's life ends. Shipping each entry raw and reducing server-side is possible in principle, but it multiplies your beacon volume and moves subtle, spec-shaped logic into a place where nobody will maintain it correctly. ## Largest contentful paint: keep the last candidate The browser emits an entry each time a new largest contentful element paints. A text block paints at 600 ms; the hero image lands at 1900 ms and is bigger; you get two entries. The metric is the last one. Reporting on arrival means every page contributes its earliest candidate, and your dashboard is confidently, systematically optimistic. Reporting also *stops* at the first user interaction — a click or key press ends candidacy, on the reasoning that content painted after the user has already engaged is no longer part of the initial-load experience. So there is no "it stopped changing" signal you can wait for; you keep the latest value and finalise at the end. ```javascript let lcp; new PerformanceObserver((list) => { const entries = list.getEntries(); lcp = entries[entries.length - 1]; }).observe({ type: 'largest-contentful-paint', buffered: true }); ``` One more trap: `renderTime` on an LCP entry is 0 for a cross-origin image whose response lacks `Timing-Allow-Origin`, so collection code falls back to `loadTime`, which is marginally earlier and marginally flattering. ## Interaction latency: group by interactionId `PerformanceEventTiming` entries (`type: 'event'`) describe individual events, and one user interaction spans several of them. A tap yields `pointerdown`, `pointerup` and `click`; a key press yields `keydown`, `keypress`, `keyup`. The entries belonging to one logical interaction share a non-zero `interactionId`. The latency of *the interaction* is derived from that group — you cannot read it off any single entry, and summing the entries double-counts. Two further mechanics matter. First, the observer's `durationThreshold` option: the default reporting floor is around 100 ms, so ordinary-but-not-great interactions are invisible unless you pass a lower value (the effective minimum is 16 ms). Second, the page-level value is chosen across all interactions on the page rather than being the last or the mean, so the collector has to retain a small set of the worst interactions for the page's lifetime and pick from it at the end. ```javascript observer.observe({ type: 'event', durationThreshold: 40, buffered: true }); ``` ## Layout shifts need windowing `layout-shift` entries carry a `value` and a `hadRecentInput` flag. Shifts that immediately follow user input are excluded, and the remaining ones are grouped into windows before they become the page's score — so a collector that sums every entry it sees will over-report, sometimes dramatically on a long-lived page. This grouping rule is precisely the kind of specification detail that argues for a maintained library rather than an in-house reducer. ## Finalising and sending The page's final values are known only when the page stops being used. The reliable signal is `visibilitychange` firing with `document.visibilityState === 'hidden'` — it covers tab switches, app switches on mobile, and closing — with `pagehide` as a secondary hook for the cases a given browser handles differently. Send with `navigator.sendBeacon(url, body)`, which queues the request in the browser rather than the document, so it survives the page going away; a `fetch(url, { keepalive: true })` is the equivalent when you need headers or a response. Guard against double-sending: a page can go hidden and come back, so mark the payload as sent, and if you report again later send only the delta or a distinguishing flag. What not to use: `unload` and `beforeunload`. They are unreliable on mobile, where a tab is often discarded without them firing at all, and registering an `unload` listener makes the page ineligible for the back/forward cache — meaning your monitoring code degrades the very metric it is measuring. ## Why the library exists Everything above — last-candidate LCP, interaction grouping and threshold, shift windowing, prerender and back/forward-cache handling, the hidden-page finalisation — is what the `web-vitals` library encapsulates behind `onLCP`, `onINP`, `onCLS`, `onTTFB` and `onFCP`, each calling you back with a finalised value. It also offers an attribution build that adds diagnostic context, such as which element the LCP candidate was. Hand-rolling collection is a legitimate exercise for understanding the APIs; shipping a hand-rolled version means owning a moving specification forever. The honest interview answer names both: here is how it works underneath, and here is why I would not maintain it myself.