Interaction to Next Paint — measures how quickly your page responds to user input. Should be under 200ms (good) or under 500ms (acceptable). Replaced FID in March 2024. Most pages with poor INP have heavy JavaScript event handlers or excessive third-party scripts blocking the main thread.
INP (Interaction to Next Paint) is Google's responsiveness metric — the third Core Web Vital alongside LCP and CLS. It replaced FID (First Input Delay) on March 12, 2024 because FID only measured the first interaction, while INP measures all interactions throughout the page lifetime.
**INP thresholds (per page, mobile field data):**
- **Good:** under 200ms - **Needs improvement:** 200ms–500ms - **Poor:** over 500ms
**What INP actually measures:**
The time from when a user clicks, taps, or types until the next visual update appears on screen. Includes input delay, processing time, and presentation delay. Google reports the **highest INP value** observed during the page session (or the 98th percentile if more than 50 interactions).
**Why your INP is poor (top causes in order):**
**1. Heavy JavaScript event handlers.** A click handler that runs 500ms of synchronous JavaScript blocks the main thread for that entire duration. Common culprits: analytics initialization on first interaction, A/B testing tools, personalization engines, "lazy" widget loaders that turn out to be eager.
**Fix:** use `requestIdleCallback` for non-critical work. Defer analytics. Move heavy computation to web workers. Profile with Chrome DevTools' Performance panel — anything blocking the main thread for >50ms after an interaction is a problem.
**2. Third-party scripts.** Chat widgets, customer support tools, marketing tags, A/B testing platforms — each one adds main-thread work. Most sites have 8–15 third-party scripts; only 3–5 are typically essential.
**Fix:** audit your tag manager. Remove anything not actively producing measurable business value. Defer or async-load remaining tags.
**3. Excessive React/Vue re-renders on interaction.** A click that triggers a state change rippling through 500 components causes hundreds of milliseconds of reconciliation. Common in SPAs that haven't been optimized for component memoization.
**Fix:** use React.memo, useMemo, useCallback strategically. Profile with React DevTools Profiler. Lift state down (scope state changes to the smallest possible component tree).
**4. Large DOM size.** Pages with 3,000+ DOM nodes have inherently slow style recalculation and layout. Common in long e-commerce category pages, infinite-scroll feeds, and content-heavy long-form pages.
**Fix:** virtualize long lists (react-window, react-virtualized). Lazy-render below-the-fold content. Avoid deeply nested div soup.
**5. Synchronous layout-trigger property changes.** JavaScript that reads and writes layout properties in the same tick (e.g., reading offsetHeight then setting style.height) causes forced synchronous layouts.
**Fix:** batch DOM reads and writes. Use `requestAnimationFrame` for visual updates.
**Diagnosing INP in real-world data:**
- **Search Console > Core Web Vitals report** shows your INP at site-aggregate level - **CrUX dashboard** (CrUX.dev or the BigQuery export) shows per-URL field data - **Chrome DevTools > Performance Insights** shows local diagnosis - **PageSpeed Insights** shows both lab data and field data side-by-side
**The 2026 reality:** roughly 35% of all webpages currently fail INP on mobile. The ones that pass typically have aggressive JavaScript discipline — minimal third-party scripts, proper code-splitting, and main-thread protection during interactions.
- **How do I fix a poor Largest Contentful Paint (LCP) score?** — LCP should be under 2.5 seconds on mobile. Five fixes that work for 90% of sites: (1) optimize and preload your hero image, (2) eliminate render-blocking resources above the fold, (3) use a CDN, (4) enable HTTP/2 or HTTP/3, (5) reduce server response time (TTFB) under 600ms. - **What's a good Core Web Vitals score in 2026?** — All three metrics in the 'Good' threshold (LCP <2.5s, INP <200ms, CLS <0.1) at the 75th percentile of mobile users over the trailing 28 days. About 40% of websites achieve this in 2026 — passing all three is a meaningful competitive edge. - **Lab vs field data — which one does Google actually use?** — Field data (real user measurements) is what Google uses for ranking. Lab data (synthetic Lighthouse runs) is for debugging only. A site can have perfect Lighthouse scores and still fail Core Web Vitals if real users experience poor performance. - **Why does my React/Vue/Angular SPA have poor Core Web Vitals?** — SPAs ship large JavaScript bundles that block the main thread during hydration. The browser must download, parse, compile, and execute the bundle before the page becomes interactive. Solutions: code-splitting, server-side rendering, partial hydration, or migrating to a meta-framework (Next.js, Nuxt, Remix, Astro).