Web Vitals Attribution

Web Vitals attribution adds diagnostic context to a metric, helping connect a poor LCP, INP, or CLS result to a resource, element, interaction, or timing phase. It helps guide investigation, but does not by itself prove the root cause or change the metric value.

A Web Vital score tells you how a page performed; attribution provides clues about what contributed to that result. In real-user monitoring (RUM), capture both the metric and selected attribution data so you can investigate patterns across users, devices, and page types.

For LCP, attribution can identify the largest-contentful element and its resource URL, then break down the time into phases such as time to first byte, resource load delay, resource load duration, and element render delay. These phases help distinguish a slow response from a resource discovered too late or content rendered late.

For INP, attribution describes the interaction associated with the measured delay, including its target and timing phases: input delay, event processing, and presentation delay. This helps narrow the investigation to, for example, time spent waiting before handlers run versus time spent processing an interaction or rendering its result.

For CLS, attribution can identify the element associated with the largest shift and provide information about the shift and page load state. Use this to inspect layout changes around the reported time; the element identified is a clue, not always the sole cause of the movement.

The `web-vitals/attribution` entry point provides attribution data alongside metrics. Send only useful, appropriately sampled fields to your monitoring endpoint, and avoid treating one user’s report as representative. Compare field data across segments and validate suspected causes with browser performance tools or a targeted reproduction.

Key points

• Attribution supplements a metric with diagnostic context; it does not replace the metric.
• LCP attribution helps investigate the content element, resource, and loading/rendering phases.
• INP attribution helps locate the interaction and separate input delay, processing time, and presentation delay.
• CLS attribution points to a shift source and related timing context for investigation.
• Use aggregated field data and follow up with targeted profiling before choosing a fix.

Interview questions

What does Web Vitals attribution add to a metric?

It adds diagnostic context alongside a metric such as LCP, INP, or CLS. Depending on the metric, that context can include a relevant element, resource, interaction, or timing breakdown. The extra data helps narrow an investigation, but it does not prove that the identified item alone caused the result.

How would you investigate poor LCP using attribution?

First, check which element and resource were associated with LCP. Then inspect the timing breakdown: a long time to first byte suggests a response-path issue, while a long resource load delay can point to late discovery or prioritization. A long resource load duration suggests the resource itself takes time to transfer, whereas a long element render delay points toward when the content becomes renderable. I would confirm the likely cause with field segmentation and a browser trace before changing the page.

What do the INP attribution phases tell you?

Input delay measures time from the interaction until its event processing can begin. Processing duration covers the handling of the interaction's event callbacks. Presentation delay covers the time until the next visual update is presented. Comparing these phases helps decide whether to inspect main-thread contention, event-handler work, or rendering and presentation, while the interaction target helps identify the affected control.

How should a team use CLS attribution when investigating layout shifts?

Use the reported shift target and timing context to find what moved and inspect the page around that moment. Check for changes such as content being inserted, dimensions changing, or late-loaded assets affecting layout. The attributed target is not necessarily the only element responsible, so reproduce the shift or inspect a trace before deciding on a fix. Compare reports across sessions to see whether the pattern is consistent.

How would you design production collection for attribution data?

I would collect metric values and identifiers together with a deliberate, metric-specific subset of attribution fields. I would review privacy implications, avoid unnecessary user-identifying data, and control payload volume through sampling or filtering where appropriate. On the analysis side, I would aggregate by relevant dimensions such as page type and device class, while checking that the sample is representative. Finally, I would use the data to form hypotheses and validate them with targeted profiling.