[Sentry] Extending Sentry Analysis to Systematically Reduce High INP Events

[mountiny]

Coming from a proposal in Slack here

Background

INP (Interaction to Next Paint) is a core Web Vitals metric that measures how long the UI remains unresponsive after a user interaction — capturing the real, user-perceived responsiveness of the product.
Recommended thresholds (75th percentile) https://web.dev/articles/inp:

• ≤ 200 ms — good
• 200–500 ms — needs improvement
• over 500 ms — poor
  Across our production environment, over the last 14 days Sentry recorded 71,000 user interactions, with a 75th percentile INP of 552.84 ms, placing our responsiveness firmly in the “poor” range.

Problem

Many interactive elements in the app cause the browser to freeze for 500+ ms before updating the UI or showing a loading state. This delay makes users unsure whether their action was registered or whether the application is performing the task they requested.

Solution

Expand our Sentry workflow to systematically identify and improve slow user interactions, with a clear focus on reducing INP:

1. Improve element labeling in Sentry

• Replace auto-generated selectors with meaningful labels to accurately map INP events to specific UI elements.
• For example, the element div.css-146c3p1.r-1udh08x.r-1udbk01.r-1iln25a on /search currently represents more than five different user actions, making meaningful analysis extremely difficult.
• We still need to determine the best implementation approach, but the plan is to test Sentry’s automatic component labeling for React (https://docs.sentry.io/platforms/javascript/guides/react/features/component-names/) and explore a solution for custom labels where automatic labeling is insufficient.

2. Identify the slowest and most frequent interactions

• Use Sentry’s INP data to determine which actions are both common and slow, and create focused GitHub issues for each problematic interaction.

3. Optimize each interaction

• Fix INP issues by addressing the specific bottlenecks that cause long freezes after user actions.
• Refactor and improve the overall performance and quality of the components involved in frequently used interactions, ensuring they deliver better real-world responsiveness.
• Verify improvements by re-checking the INP metric in Sentry for each optimized interaction.

Below I’m including a screenshot of the currently most problematic interactions.

[melvin-bot]

Triggered auto assignment to @JmillsExpensify (NewFeature), see https://stackoverflowteams.com/c/expensify/questions/14418#:~:text=BugZero%20process%20steps%20for%20feature%20requests for more details. Please add this Feature request to a GH project, as outlined in the SO. Remember to draft any necessary HelpDot updates by following the instructions here.

[melvin-bot]

Triggered auto assignment to Design team member for new feature review - @dannymcclain (NewFeature)

[dariusz-biela]

The current Sentry implementation doesn’t help much in our specific case, so improving element labeling on our side is quite limited. In particular:

• it only walks 5 parent levels up the DOM,
• it stops once the selector exceeds 80 characters.

Over the last two days I’ve been digging into how Sentry measures INP, and I’ve started preparing a patch to improve how the library handles interacted elements in our scenario.

Before going further, Mariusz Stanisz suggested that I first raise the issues directly with Sentry to see whether they already plan improvements or are open to addressing these limitations.

Here are the two issues I submitted:

• INP metric: Too many spans with <unknown> target due to disappearing DOM elements getsentry/sentry-javascript#18409 — INP spans often report <unknown> because clicked elements are removed from the DOM
• INP metric: CSS selector generation is too shallow and produces highly ambiguous selectors getsentry/sentry#104128 — Generated CSS selectors for INP are too shallow and frequently ambiguous