Slow interactions (by hostname)

This health check detects hostnames responsible for slow interaction handling (INP) based on real user data.

It uses Long Animation Frame (LoAF) data to identify which scripts (first- or third-party) are executing during slow interactions.

Each todo represents a hostname whose JavaScript execution contributes significantly to interaction delays for a specific device type.

About this check

When this check is triggered

You’ll see this check when:

  • A hostname is consistently involved in slow interactions
  • The impact is visible in real user data (p75, p85, p90)
  • There are enough events to validate the pattern
  • Script execution during interactions leads to high INP

This corresponds with our RUMvision third party dashboard.

What you’ll see

Each todo includes:

  • Hostname
  • Device type (desktop, mobile, tablet)
  • Interaction latency tied to script execution

Example:

Investigate slow interaction on mobile by www.googletagmanager.com
The hostname www.googletagmanager.com is causing high INP on mobile.

Why this matters

INP is heavily influenced by JavaScript execution during interactions.

This check helps you identify:

  • Whether the issue is first-party code or third-party scripts
  • Which external providers are slowing down interactions
  • Where to focus optimization efforts

Unlike element-based checks, this gives you root-cause visibility at hostname and script level.

How to fix it

Most issues come from:

  • Third-party scripts executing on interaction (e.g. GTM, analytics)
  • First-party bundles doing heavy work during input
  • Long tasks triggered by event listeners
  • Multiple scripts reacting to the same interaction
  • Synchronous logic across multiple domains
  • Tag managers triggering multiple downstream scripts

Possible causes and fixes:

1. Identify 1st vs 3rd-party

Start by understanding ownership.

What to check

  • Is the hostname yours or external?
  • Does it belong to analytics, ads, A/B testing, or widgets?

Why this matters

  • First-party → you can directly optimize
  • Third-party → you may need to limit, defer, or replace

2. Reduce third-party impact

Third-party scripts are a common source of INP issues.

What to check

  • Scripts loading from:
  • Tag managers
  • Analytics tools
  • A/B testing platforms
  • Chat or personalization tools

What to do

  • Remove unused integrations
  • Limit scripts loaded on critical pages
  • Load scripts after interaction where possible
  • Use async or lazy loading strategies

3. Audit Google Tag Manager (GTM)

GTM is often a major contributor.

What to check

  • Number of triggers firing on interaction
  • Tags executed on click, submit, or input
  • Chained triggers (one event triggering many tags)

Why this matters

  • Each dataLayer.push() can trigger multiple scripts
  • More triggers = more main-thread work during interaction

What to do

  • Reduce number of triggers and tags
  • Audit which events are actually needed
  • Avoid firing tags on every interaction

4. Control tracking in your own code

Instead of relying fully on GTM, control push events from your own codebase:

setTimeout(() => {
  dataLayer.push({ event: 'interaction' });
  }, 0);

Why this helps

  • Defers tracking work
  • Prevents blocking the interaction itself
  • Gives you full control over execution timing

5. Reduce main-thread work

Whether first- or third-party, the problem is execution time.

What to check

  • Long tasks during interaction
  • Heavy script execution tied to events

What to do

  • Split long tasks
  • Defer non-critical work
  • Use modern scheduling APIs

Example

await scheduler.yield();

6. Prevent multiple scripts reacting to one interaction

Interactions often trigger multiple listeners.

What to check

  • Multiple libraries listening to the same event
  • Duplicate tracking or logging

What to do

  • Consolidate event handling
  • Avoid duplicate listeners across scripts

7. Limit script execution scope

Not every script needs to run everywhere.

What to check

  • Global scripts running on all pages
  • Scripts attached to all interactions

What to do

  • Load scripts conditionally per page/template
  • Scope listeners to specific elements or flows

8. Consider server-side tagging

Move event distribution away from the browser where possible.

What to check

  • Does a single interaction trigger multiple 3rd-party tags or scripts client-side?
  • Are analytics, ads, and marketing vendors all listening to the same browser-side event?
  • Is your GTM container distributing interaction events to many vendors in the browser?

Why this matters

  • Client-side tagging adds main-thread work during interactions
  • Each extra vendor script or trigger can increase INP
  • Server-side tagging can reduce the number of client-side event listeners and scripts involved in the interaction

What to do

  • Send a single event from the browser to your own server-side tagging endpoint
  • Let the server distribute that event to multiple analytics or ad platforms
  • Keep the client-side event handler lightweight and defer non-critical tracking work where possible

Further debugging

How to approach this in RUMvision

  1. Open the todo
  2. Identify the hostname
  3. Determine:
    • First-party or third-party
  4. Reproduce the interaction:
    • Use Chrome DevTools → Performance panel
    • Record interaction
  5. Look for:
    • Long tasks
    • Script execution from the flagged hostname
  6. Reduce or defer execution
  7. Monitor improvement over the next 7 days

Pro tip

Focus on:

  • Third-party-heavy pages
  • High-interaction flows (checkout, filtering, search)
  • Mobile devices (more sensitive to CPU constraints)

Reducing or deferring a single heavy third-party script can improve interaction responsiveness across multiple elements at once.

Table of Contents