feat(attributes): Add LCP and INP subpart attributes

[logaretm]

LCP and INP only report a total, so there is no way to see which phase made them slow, this can be fixed by introducing web vital subparts.

We already report some of these partially like TTFB, so this PR standardises the other remaining attributes.

New Attributes

Attribute	Represents	Measured as
browser.web_vital.lcp.resource_load_delay	Time between the document's first byte and the browser starting to load the LCP resource	resource requestStart minus TTFB
browser.web_vital.lcp.resource_load_duration	Time to load the LCP resource	resource responseEnd minus requestStart
browser.web_vital.lcp.element_render_delay	Time between the LCP resource finishing loading and the LCP element rendering	LCP value minus resource responseEnd
browser.web_vital.inp.input_delay	Time between the user interacting and the event handlers starting	processingStart minus startTime
browser.web_vital.inp.processing_duration	Time the event handlers took to run	processingEnd minus processingStart
browser.web_vital.inp.presentation_delay	Time between the handlers finishing and the next frame being presented	startTime + duration minus processingEnd

Resources

• Optimize LCP (web.dev)
• Optimize INP (web.dev)
• Common misconceptions about how to optimize LCP (web.dev)
• PerformanceEventTiming (MDN)
• LargestContentfulPaint (MDN)
• LargestContentfulPaint.loadTime (MDN)
• LargestContentfulPaint.renderTime (MDN)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
sentry-conventions	Ready	Preview	Oct 14, 2026 2:42pm UTC

[github-actions]

Semver Impact of This PR

🟡 Minor (new features)

📋 Changelog Preview

This is how your changes will appear in the changelog.
Entries from this PR are highlighted with a left border (blockquote style).

---

New Features ✨

Attributes

• Add LCP and INP subpart attributes by logaretm in #712

• Add http.request.duration by loewenheim in #697

Bug Fixes 🐛

• (attributes) Apply consistent scrubbing across deprecations by mjq in #692

Internal Changes 🔧

• (repo) Update CODEOWNERS to include @giortzisg by Lms24 in #708

---

_{🤖 This preview updates automatically when you update the PR.}

[adityareddy-dev]

The three phase suffixes match the experimental attributes in OTel browser #486, though the prefixes differ: browser.web_vital.inp.{input_delay,processing_duration,presentation_delay} here maps to browser.web_vital.attribution.{input_delay,processing_duration,presentation_delay} there. Those names are still proposals, with agreement tracked on #471.

There is also an absence distinction worth carrying into that discussion. These definitions omit all three phases when there is no interaction to attribute, while the OTel draft preserves the web-vitals dummy INP timings, including zero input/processing and a presentation delay equal to the value. Could we link the naming discussion and document that difference alongside the mapping? Consumers translating between the two would otherwise need to infer whether missing phases and reported zeros mean the same thing.

[logaretm]

Thanks! Since those names are still experimental and not in semconv, I'd rather not document a mapping yet. Happy to align in a way or another once #471 settles.

Omitting is intentional. web-vitals reports a placeholder INP for soft navs with no recorded interaction, so 0/0/value would pull input delay and processing toward 0, make presentation look like the bottleneck, and make the subpart trends follow how many soft navs happen rather than actual perf.

[Lms24]

Thanks, this looks fine to me!

I agree with for now, not fully aligning to the experimental OTel standard. To be quite frank, I much prefer our prefixed versions here, given that the sub part attributes already differ between LCP and INP, so having the vital in the prefix sounds fair to me (besides that this is what we already do with other web vital attributes).

One case we must keep in mind from Sentry's side: Sentry users can use span attributes as "Span Metrics", meaning, they can build dashboards and queries based on the values these hold. So, an idiomatic attribute name is much easier to reason with than having more generic attributes that must be filtered by web vital type via an attribute.

I don't rule out on aligning with OTel at some point in the future by the way. There's a UX and migration cost to this though and timing-wise, we just switched to the new browser.web_vital.* attributes a few months before they were added to OTel semconv.
We will definitely keep an eye on the OTel browser conventions. Nice seeing some movement there :) Thanks for chiming in @adityareddy-dev!

cc @logaretm let's wait the usual 2-3 days for other reviewers to share their thoughts