Most teams fought hard to improve LCP and CLS. Now Interaction to Next Paint (INP) is the conversion killer hiding in plain sight—users click, nothing seems to happen, and confidence drops. This article explains what INP is, how it replaced FID, and the exact steps UK SMEs can take to get into the “Good” range quickly and keep it there.

What Is INP Core Web Vitals—and Why It Replaced FID#

INP (Interaction to Next Paint) captures the responsiveness of your page throughout a user’s visit. It looks at the latency between a user’s action (tap, click, key press) and the next paint that reflects the UI update. Unlike FID, which only measured the delay before the first interaction, INP covers many interactions and reports the worst—or near-worst—case as your score. That makes it a far better proxy for how responsive your product feels.

• INP vs FID: INP measures many interactions; FID only the first.
• Scope: INP includes event handling, UI updates, and rendering—not just input delay.
• Outcome: Lower INP means the interface feels instant and trustworthy.

Core Web Vitals Thresholds for INP#

• Good: ≤ 200 ms
• Needs Improvement: > 200 ms and ≤ 500 ms
• Poor: > 500 ms

How to Measure INP: Field vs Lab#

Treat INP like a product metric, not a one-off audit. Use both field and lab data, but make decisions from real users first.

• Field (Real User Monitoring): Collect real user metrics via a small script (e.g., PerformanceObserver) to record INP across routes, device classes, and traffic sources.
• CrUX & Search Console: Use aggregated, privacy-safe data to benchmark against the wider web and spot regressions.
• PageSpeed Insights & Lighthouse: Great for reproducible lab tests and quick feedback loops, but remember lab ≠ reality.
• Segment by device and network: INP problems often show up first on mid-tier Android devices or under flaky connectivity.
• Track alongside business outcomes: Pair INP percentiles with conversion rate, form completion, and funnel drop-off.

Common Culprits That Inflate INP#

If your interface feels sticky or slow after taps and clicks, you’re likely blocking the main thread or doing too much work during event handlers.

• Heavy JavaScript bundles and hydration work that coincides with user input.
• Long tasks (> 50 ms) caused by parsing, compilation, or synchronous logic.
• Expensive event handlers (e.g., complex validation on every keystroke).
• Layout thrashing: repeated style recalculations and forced synchronous layouts.
• Third-party scripts (tags, widgets, chat, A/B testing) executing during interactions.
• Rendering hotspots: large DOM updates, heavy SVG/canvas drawing, or blocking CSS.

Quick Wins to Improve INP This Week#

1. Defer non-critical JavaScript: mark scripts as async or defer and load third-party tags after first interaction or when idle.
2. Break long tasks: chunk heavy work with requestIdleCallback, setTimeout(0), or postMessage to a Web Worker.
3. Slim your runtime: tree-shake, code-split, and remove unused libraries; prefer native browser features where possible.
4. Hydration strategy: adopt partial/streaming or islands architecture to avoid big main-thread blocks on interaction.
5. Make event handlers light: debounced validation, minimal DOM reads/writes, avoid sync XHR, and cache computed values.
6. Use passive listeners for scroll/touch where safe to avoid blocking the main thread.
7. Prioritise UI feedback: show immediate affordances (pressed states, skeletons, optimistic UI) before heavy logic runs.
8. Contain layout changes: use CSS contain and will-change carefully to limit expensive reflows.

Event Handler Patterns That Keep INP Low#

const onInput = (e) => {
  // Give instant visual feedback first
  e.target.classList.add('is-updating');
  // Defer heavy work
  requestIdleCallback(() => {
    validateField(e.target.value); // cheap validation only
  });
};

inputEl.addEventListener('input', onInput, { passive: true });

Resource Hints and Priority#

<!-- Defer non-critical work and help the browser prioritise correctly -->
<link rel="preload" href="/fonts/brand.woff2" as="font" type="font/woff2" crossorigin>
<link rel="modulepreload" href="/assets/above-the-fold.mjs">
<!-- Keep non-critical below-the-fold scripts deferred -->
<script type="module" src="/assets/below-the-fold.mjs" defer></script>

JavaScript Diet: Cut, Split, and Schedule#

Most poor INP scores trace back to too much JavaScript running at the wrong time. Reduce, lazy-load, and schedule work carefully.

• Bundle hygiene: turn on tree-shaking, remove polyfills for modern browsers, audit dependencies quarterly.
• Code-split by route and interaction: deliver only what’s needed for first paint and initial actions.
• Lazy-hydrate or island-render components that don’t need immediate interactivity.
• Move heavy transforms off the main thread via Web Workers; keep messages tiny.
• Guard third-parties: load after user intent (e.g., on scroll to footer) or via a tag manager with strict consent rules.

UI Patterns That Reduce Perceived and Actual Latency#

• Optimistic UI for cheap actions; reconcile on server response.
• Skeletons for list/table loads; avoid layout shifts mid-interaction.
• Disable and label action buttons immediately after click; prevent double submits.
• Micro-copy near inputs to reduce validation work later.

Case Snapshot: From 420 ms to 160 ms INP#

A mid-market ecommerce brand saw median INP around 420 ms, with checkout interactions spiking beyond 600 ms on mobile. We profiled event handlers, split the payment widget into an island, deferred non-critical third-parties, and moved fraud checks into a Worker. We also added instant visual feedback on “Pay now”. Within two sprints, INP dropped to 160 ms on the 75th percentile and checkout completion rose 7.4%—the team kept a small performance budget to prevent regression.

Step-by-Step: Your INP Improvement Plan#

1. Baseline: capture INP percentiles (50/75/95) for key journeys and device classes.
2. Triage: identify the worst offending routes and interactions with profiling.
3. Stabilise: ship quick wins (defer third-parties, passive listeners, thin handlers).
4. Refactor: code-split, introduce islands/partial hydration, and break long tasks.
5. Offload: move heavy work to Workers; precompute on the server where possible.
6. Verify: rerun field checks; compare conversion rate and support tickets.
7. Govern: add a performance budget and guardrails in CI/CD.

Instrumentation: See the Delay You Feel#

You can capture INP in the browser today and send it to your analytics stack. Track by page type, device, and traffic source. Tie everything back to revenue.

import { onINP } from 'web-vitals';

onINP((metric) => {
  // Example payload: send to your analytics endpoint
  navigator.sendBeacon('/rum', JSON.stringify({
    name: metric.name,
    value: metric.value, // INP in ms
    rating: metric.rating, // 'good' | 'needs-improvement' | 'poor'
    path: location.pathname,
    ts: Date.now(),
  }));
});

Platform-Specific Tips (React/Next.js)#

• Prefer Server Components for static/slow-changing content; hydrate only interactive islands.
• Use dynamic() to lazy-load heavy client components; set ssr: false for non-critical widgets.
• Keep forms simple: controlled inputs sparingly; debounce onChange and validate on blur/submit.
• Preload critical routes and above-the-fold assets; avoid runtime CSS-in-JS for core UI.
• Ensure priority hints (preload fonts, above-fold modules) and defer analytics until after first interaction.

Monitoring & Guardrails#

• Dashboards: track INP percentiles by route and device class; alert on regressions.
• Budgets: fail builds if JS bundles or long tasks exceed thresholds.
• Canaries: roll out heavy features to a small cohort and watch INP before 100% release.
• Quarterly audits: review third-party tags, remove duplicates, and renew consent settings.

Pitfalls to Avoid#

• Chasing lab scores only: field users on real devices decide your revenue.
• Loading multiple analytics suites that duplicate work during interactions.
• Doing heavy DOM measurement inside event handlers; pre-compute or memoise.
• Relying solely on throttling profiles; validate on actual mid-range devices.

Checklist: From Audit to Impact#

• Field baseline for INP at p50/p75/p95; segment mobile vs desktop.
• Top 3 offending interactions identified with profiles/long-tasks list.
• Third-party governance: lazy-load and idle-until-urgent.
• Hydration and JS budgets set; code-split confirmed per route.
• Worker offloading in place for heavy transforms.
• UI feedback within 100 ms: pressed state, skeletons, optimistic UI.
• Monitoring alerts on INP regressions tied to releases.
• Conversion dashboard correlates INP with revenue KPIs.

How CodeKodex Can Help#

We run focused audits, prioritise fixes by business impact, and work alongside your team to ship improvements without derailing roadmaps. You get a clear plan, rapid wins, and a performance culture that lasts.

Frequently Asked Questions#

Next Steps#

If your team needs help diagnosing and fixing INP, our engineers can deliver a lightweight audit and an implementation plan that protects brand experience and boosts conversions—without a rebuild.