---
title: "Interaction to Next Paint (INP) Guide"
description: "Master INP optimization with practical fixes for JavaScript execution, DOM operations, and event handlers. Improve responsiveness across your site."
canonical_url: "https://unlighthouse.dev/learn-lighthouse/inp"
last_updated: "2025-01-18"
---

<audit-impact metric="inp">



</audit-impact>

INP is the [hardest Core Web Vital for mobile users](https://almanac.httparchive.org/en/2024/performance). While 97% of desktop pages pass, only 74% of mobile pages achieve good INP. That 23-point gap matters - mobile users make up [over 60% of web traffic](https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet).

INP [replaced FID as a Core Web Vital on March 12, 2024](https://web.dev/blog/inp-cwv-march-12). The bar got higher: [93% of sites passed FID](https://web.dev/blog/inp-cwv), but FID only measured input delay on the first interaction. INP measures everything - every click, tap, and keypress throughout the entire page session.

## What is INP?

Interaction to Next Paint measures responsiveness - how long it takes for the page to visually respond after a user interacts. Google uses this definition from the Lighthouse audit:

> "Interaction to Next Paint measures page responsiveness, how long it takes the page to visibly respond to user input."

**INP Thresholds:**

<table>
<thead>
  <tr>
    <th>
      Score
    </th>
    
    <th>
      Rating
    </th>
    
    <th>
      What It Feels Like
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      ≤200ms
    </td>
    
    <td>
      Good
    </td>
    
    <td>
      Instant, responsive
    </td>
  </tr>
  
  <tr>
    <td>
      200–500ms
    </td>
    
    <td>
      Needs Improvement
    </td>
    
    <td>
      Noticeable lag
    </td>
  </tr>
  
  <tr>
    <td>
      >500ms
    </td>
    
    <td>
      Poor
    </td>
    
    <td>
      Frustratingly slow
    </td>
  </tr>
</tbody>
</table>

**Score Weight:** INP doesn't directly affect Lighthouse Performance scores in lab mode. Instead, Lighthouse uses [Total Blocking Time (TBT)](/glossary/tbt) as a proxy, which accounts for **30%** of the score. In field data (CrUX), CrUX measures INP directly.

## What triggers INP

INP only measures discrete interactions - events that have a clear start and end:

<table>
<thead>
  <tr>
    <th>
      Interaction Type
    </th>
    
    <th>
      Examples
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        Clicks
      </strong>
    </td>
    
    <td>
      Button clicks, link clicks, checkbox toggles
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Taps
      </strong>
    </td>
    
    <td>
      Mobile screen taps, touch inputs
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Key Presses
      </strong>
    </td>
    
    <td>
      Typing in inputs, keyboard shortcuts
    </td>
  </tr>
</tbody>
</table>

**Not measured:** Scrolling, hovering, and pinch-to-zoom. These are continuous interactions with different performance characteristics.

The browser tracks all qualifying interactions during the page session. Your INP score is typically the worst interaction (or 98th percentile on pages with many interactions).

## Why INP matters

### User experience

Users expect instant feedback. [Research shows](https://web.dev/articles/defining-core-web-vitals-thresholds) that delays over 200ms start to feel sluggish. Past 500ms, users assume something is broken.

The consequences of poor INP:

- Users click multiple times, triggering duplicate actions
- Forms feel unresponsive, causing input errors
- E-commerce checkouts get abandoned
- Users perceive your site as low-quality

Since [90% of user time on a page happens after it loads](https://web.dev/articles/inp), INP captures the experience that matters most.

### SEO impact

INP officially replaced FID as a [Core Web Vital ranking factor on March 12, 2024](https://developers.google.com/search/docs/appearance/core-web-vitals). While FID only measured the *first* interaction, INP influences ranking eligibility by measuring *all* interactions.

For 2025, the bar is strict: Google treats <200ms as the "Good" threshold for ranking boosts. Sites consistently failing this metric see reduced visibility in competitive search results.

### Industry benchmarks & competitive advantage

Passing Core Web Vitals is harder than it looks. As of mid-2024, [only ~47% of websites passed all Core Web Vitals](https://almanac.httparchive.org/en/2024/performance).

<table>
<thead>
  <tr>
    <th>
      Sector
    </th>
    
    <th>
      INP Pass Rate
    </th>
    
    <th>
      Opportunity
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        eCommerce
      </strong>
    </td>
    
    <td>
      Low
    </td>
    
    <td>
      High - most catalogs are heavy
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        News/Media
      </strong>
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      High - ad scripts kill INP
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        B2B SaaS
      </strong>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Low - usually simpler apps
    </td>
  </tr>
</tbody>
</table>

Fixing INP isn't just about compliance - it's a competitive advantage. If you're in the 47% that pass, you're likely outranking half your competitors on technical merit alone.

### Business impact

Real-world improvements show direct business correlation:

<table>
<thead>
  <tr>
    <th>
      Company
    </th>
    
    <th>
      INP Change
    </th>
    
    <th>
      Business Impact
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <a href="https://web.dev/case-studies/trendyol-inp" rel="nofollow">
        Trendyol
      </a>
    </td>
    
    <td>
      50% reduction
    </td>
    
    <td>
      1% higher click-through rate
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="https://web.dev/case-studies/economic-times-inp" rel="nofollow">
        The Economic Times
      </a>
    </td>
    
    <td>
      3x faster
    </td>
    
    <td>
      43% lower bounce rate
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="https://web.dev/case-studies/redbus-inp" rel="nofollow">
        redBus
      </a>
    </td>
    
    <td>
      72% reduction
    </td>
    
    <td>
      Higher engagement metrics
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="https://web.dev/case-studies/taboola-inp" rel="nofollow">
        Taboola
      </a>
    </td>
    
    <td>
      Multiple optimizations
    </td>
    
    <td>
      5.5% higher ad click-through
    </td>
  </tr>
</tbody>
</table>

## Understanding INP sub-parts

Every interaction breaks down into three phases. [Presentation delay often accounts for a significant portion of total INP](https://web.dev/articles/optimize-inp#presentation_delay) on average - often the overlooked bottleneck.

<table>
<thead>
  <tr>
    <th>
      Phase
    </th>
    
    <th>
      What Happens
    </th>
    
    <th>
      What Causes Delays
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        Input Delay
      </strong>
    </td>
    
    <td>
      Time waiting for main thread to become free
    </td>
    
    <td>
      Long tasks blocking the thread
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Processing Duration
      </strong>
    </td>
    
    <td>
      Time running your event handlers
    </td>
    
    <td>
      Complex handler logic
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Presentation Delay
      </strong>
    </td>
    
    <td>
      Time for browser to render the result
    </td>
    
    <td>
      DOM updates, layout, paint
    </td>
  </tr>
</tbody>
</table>

**The critical insight:** Most developers focus on processing duration because that's their code. But input delay and presentation delay often account for 60%+ of total INP. A efficient event handler still fails INP if the main thread was blocked or the DOM update triggered expensive layout.

### Try it: response time lab

Click the buttons to feel the difference between fast and slow responses:

<interactive-inp-lab>



</interactive-inp-lab>

## Common INP issues

Poor INP stems from a handful of causes. Here are the most impactful:

<table>
<thead>
  <tr>
    <th>
      Issue
    </th>
    
    <th>
      Impact
    </th>
    
    <th>
      Difficulty
    </th>
    
    <th>
      Fix Time
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <a href="/learn-lighthouse/inp/long-running-javascript">
        Long-Running JavaScript
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Hours
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/inp/heavy-dom-operations">
        Heavy DOM Operations
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Hours
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/inp/third-party-scripts">
        Third-Party Scripts
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Low
    </td>
    
    <td>
      Minutes–Hours
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/inp/total-blocking-time">
        Total Blocking Time
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Hours
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/inp/dom-size">
        DOM Size
      </a>
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Hours
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/inp/event-handler-delays">
        Event Handler Delays
      </a>
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Low
    </td>
    
    <td>
      Minutes
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/inp/hydration-issues">
        Hydration Issues
      </a>
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Hours–Days
    </td>
  </tr>
</tbody>
</table>

→ [Diagnose your specific issue](/learn-lighthouse/inp#common-inp-issues)

## How to measure INP

### Lab testing (proxy)

INP requires real user interaction - you can't measure it with an automated page load. Lab tools use Total Blocking Time (TBT) as a proxy because [TBT correlates twice as well with INP than FID did](https://github.com/GoogleChrome/web.dev/issues/8395).

**Chrome DevTools:**

1. Open DevTools → **Performance** tab
2. Check **"Web Vitals"** in settings
3. Click record → interact with the page → stop recording
4. Look for interaction events and their duration

**Lighthouse:**
Check the TBT score as your INP proxy. The thresholds are:

- **Mobile:** Good ≤200ms, Poor >600ms
- **Desktop:** Good ≤150ms, Poor >350ms

**INP Analyzer Tool:** Enter any URL to analyze interaction responsiveness - no install required.

### Field data (real users)

Field data is what Google uses for ranking. It represents actual user experience.

**PageSpeed Insights:**
Enter your URL to see CrUX (Chrome User Experience Report) INP data. This shows real-world performance from Chrome users.

**Search Console:**
The Core Web Vitals report shows which URLs pass or fail INP, grouped by similar pages.

**Web Vitals JavaScript Library:**

```js
import { onINP } from 'web-vitals'

onINP((metric) => {
  console.log('INP:', metric.value, 'ms')
  console.log('Element:', metric.attribution.interactionTarget)
  console.log('Type:', metric.attribution.interactionType)
})
```

To catch regressions automatically, set up [Lighthouse CI](/learn-lighthouse/lighthouse-ci) in your deployment pipeline.

### Mobile vs desktop gap

The INP gap between devices is massive:

<table>
<thead>
  <tr>
    <th>
      Device
    </th>
    
    <th>
      Good INP Rate (2024)
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Desktop
    </td>
    
    <td>
      97%
    </td>
  </tr>
  
  <tr>
    <td>
      Mobile
    </td>
    
    <td>
      74%
    </td>
  </tr>
</tbody>
</table>

This [23-point gap](https://almanac.httparchive.org/en/2024/performance) means mobile optimization is essential. Mobile devices have:

- Slower CPUs that struggle with JavaScript
- Touch events that trigger more complex handlers
- Limited memory causing more garbage collection pauses

Test on real mobile devices, not just throttled desktop browsers.

## Framework guides

Framework-specific INP optimizations:

<card-group>
<card icon="i-simple-icons-nextdotjs" title="Next.js">

Hydration strategies, Server Components, and useTransition.

</card>

<card icon="i-simple-icons-nuxtdotjs" title="Nuxt">

Payload optimization, lazy hydration, and component islands.

</card>

<card icon="i-simple-icons-react" title="React">

startTransition, useDeferredValue, and avoiding re-render cascades.

</card>

<card icon="i-simple-icons-vuedotjs" title="Vue">

Reactivity optimization, async components, and computed caching.

</card>

<card icon="i-simple-icons-svelte" title="Svelte">

Minimal runtime overhead and smart DOM updates.

</card>

<card icon="i-simple-icons-angular" title="Angular">

Zone.js optimization, OnPush change detection, and signals.

</card>
</card-group>

## Test your entire site

Most tools test one page at a time. That's a problem for INP - different pages have different JavaScript, different event handlers, and different interaction patterns.

Your homepage might pass while your checkout fails. Product pages might be fast until someone opens the image gallery.

[Unlighthouse](/) scans your entire site and shows TBT (INP proxy) scores for every page. You'll see which templates have issues, which pages are outliers, and whether your fixes work at scale.

The CLI is free and runs locally. Cloud adds scheduled monitoring to catch regressions before users report them.