INP Optimization: How to Fix Poor INP on Your Website

A shop owner taps "Add to cart" on a mid-range phone, and nothing seems to happen for half a second. They tap again, and now the cart has two items. That lag is what INP optimization is meant to remove, and it quietly costs Indian businesses orders, enquiries and trust.

This guide explains what Interaction to Next Paint measures, how to find the interactions that fail, and how to fix them in order of impact. It is written for business owners who need to brief a developer and for developers who want a clear process.

What is INP and what is a good score?

Interaction to Next Paint (INP) is a Core Web Vital that measures how quickly a page responds visually after a user clicks, taps or presses a key. According to web.dev's INP guide, a good INP is 200 milliseconds or less, 200 to 500 milliseconds needs improvement, and above 500 milliseconds is poor.

The score is taken at the 75th percentile of real page loads and is reported separately for mobile and desktop. In practice, it reflects one of the slowest interactions in a visit, so a single heavy filter menu can fail an otherwise fast page. INP replaced First Input Delay as a Core Web Vital in March 2024.

How do you find slow interactions?

Start with real-user data, then reproduce problems in the lab. The lab alone misleads, because a developer laptop hides what a budget Android phone on a busy network experiences.

1. Check field data. Look at the Core Web Vitals report in Google Search Console and the Chrome UX Report data in PageSpeed Insights to see which URL groups fail.
2. Collect attribution data. Add Google's web-vitals library to log which element and event caused the slow interaction.
3. Reproduce in Chrome DevTools. Open the Performance panel, throttle the CPU by 4x or 6x, and repeat the interaction.
4. Inspect long animation frames. The Long Animation Frames API is available in Chrome and reports which scripts held up a frame by more than 50 ms.

Write down the exact interaction, such as "open the size selector on a product page", because "the site is slow" cannot be fixed.

What are the three parts of a slow interaction?

Every interaction splits into three phases, and each has a different cause and fix. Diagnosing the longest phase first saves days of guessing.

If input delay dominates, the page was busy when the user tapped. If processing dominates, your own code is the problem. If presentation dominates, the browser is struggling to draw the result.

How do you fix long tasks and input delay?

Break long JavaScript tasks into smaller pieces so the browser can respond to input between them. A task that holds the main thread for more than 50 ms is considered long, and any tap during that time must wait.

The modern tool is scheduler.yield(), which pauses your function, lets the browser handle pending input, and then resumes. The Chrome team's guidance notes that it is not supported in every browser, so you need a setTimeout fallback:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function applyFilters(items) {
  for (const [index, item] of items.entries()) {
    processItem(item);
    if (index % 50 === 0) {
      await yieldToMain();
    }
  }
}

Other fixes for this phase:

• Defer non-critical scripts such as chat widgets, heatmaps and review plugins until after the page is interactive.
• Remove unused tags from Google Tag Manager. Old campaign pixels are a common hidden cost.
• Move heavy computation such as search indexing or data parsing into a Web Worker.

How do you reduce processing time in event handlers?

Keep the handler small: update what the user needs to see first, and schedule the rest. A common mistake is running analytics calls, validation and state updates in one synchronous click handler, so the screen waits for all of it.

Practical changes include:

• Show feedback immediately, such as a spinner or a pressed state, before starting slow work.
• Debounce typing handlers for search boxes and filters.
• Avoid repeated work by caching computed values instead of recalculating on every event.
• Limit change detection in frameworks. In Angular, signals and OnPush components reduce how much of the tree updates; in React, avoid re-rendering large lists on each keystroke.

Typed code helps here. Our guide to Angular vs React for business web apps explains how each framework handles updates and why structure matters for responsiveness.

How do you cut presentation delay?

Make the browser render less. Presentation delay grows with the size of the DOM, the cost of style recalculation and layout work forced by scripts.

• Keep the DOM lean. Pages with thousands of nodes, such as long catalogue grids, take longer to restyle after each change.
• Virtualise long lists so only visible rows exist in the DOM.
• Use CSS content-visibility on below-the-fold sections so the browser can skip their rendering work.
• Avoid layout thrashing, which happens when code alternately reads layout values and writes styles in a loop.
• Animate with transform and opacity instead of properties that trigger layout.

What does an INP optimization cost in India?

Cost depends on how many templates fail and how tangled the code is. As an indicative range from project experience, not a fixed quote:

Prices vary by city, codebase size and team seniority. Always ask for the audit first, because it shows whether you need a small fix or a refactor.

How to run an INP fix cycle

1. Pick the failing templates from Search Console, ordered by traffic and revenue.
2. Log attribution data for a week to learn which elements cause the slowest interactions.
3. Profile with throttling and record the three phase timings for each interaction.
4. Fix the longest phase and change one thing at a time so you can see what worked.
5. Ship and watch field data. Field data takes weeks to update, so use lab checks to confirm quickly and RUM to confirm for real.
6. Add a guard. Include an interaction test and a script budget in your release checklist.

Responsiveness also supports your search work. INP sits alongside LCP and CLS in our technical SEO checklist for Core Web Vitals, and the wider SEO service covers how page experience fits with content and crawling.

How Arham Technology approaches INP optimization

Our frontend development service treats performance and accessibility as acceptance criteria, not polish. For responsiveness problems we follow the same delivery model we use for other frontend work:

• Interface inventory: we list the screens, shared components and scripts that run on key journeys, and flag tech debt that would block fixes.
• Foundation pass: we stabilise tokens, base components and state handling so fixes do not fight inconsistent patterns.
• Feature verticals: we fix one journey at a time, such as product filters or checkout, with reviewable pull requests.
• Hardening and metrics: we instrument Core Web Vitals, validate on mid-range Android hardware and add regression tests for critical flows.

Deliverables include a prioritised findings list, typed component fixes, bundle analysis and route-level code splitting where it pays off. Our work is mostly in Angular and TypeScript, and we also support React codebases.

What should you do next?

Open Search Console, find your worst-performing template and write down one interaction on it that feels slow. Then profile it with CPU throttling and see which of the three phases is longest. If you want help, review our frontend development service and contact us with the URL and the interaction. We will share what we see before you commit to any work.