How to Fix Poor Interaction to Next Paint (INP)

If your site feels fine to you but visitors say it is "laggy", or Google Search Console shows a red or amber INP warning, this guide is for you. Interaction to Next Paint (INP) measures how long a page takes to visibly respond when someone taps a button, opens a menu or types in a field. You will learn to read your INP data, find the slow interaction and fix the usual causes, whether you manage the site yourself or brief a developer.

In short: INP is the Core Web Vital that replaced First Input Delay in March 2024. A good score is 200 milliseconds or less, measured on real visitors. Check your real-user data, record the slowest click or tap in Chrome, then trim whatever is keeping the browser busy: usually your own scripts, third-party widgets or a heavy theme.

What INP actually measures

Each time a visitor clicks, taps or presses a key, the browser must run some code and then draw the result. INP is the time from that interaction to the next frame appearing on screen. Scrolling and hovering do not count.

Google's published thresholds are:

A page's INP broadly reflects its slowest interactions during a visit. To pass the Core Web Vitals assessment, the 75th percentile of real visits must be "good", so a slow menu or "Add to cart" button can fail a page that feels fine on your own fast device. Google explains the details on web.dev.

The delay has three parts, and fixes differ for each:

• Input delay: the browser is busy with something else when the tap arrives.
• Processing time: your event handler code is running.
• Presentation delay: the browser is working out and drawing the next frame.

Step 1: Check your real-user data

INP is a field metric, meaning it comes from real visits. Lab tools can only estimate it.

• Search Console: the Core Web Vitals report groups similar URLs, so a flagged URL often represents a whole template, such as every product page.
• PageSpeed Insights: the real-user section at the top is based on Chrome user data. Check whether it shows the URL or the whole origin; quiet pages often fall back to origin-wide figures.
• No data: low-traffic pages may show nothing. Missing INP does not mean good INP.

Field reports cover a rolling 28-day window, so improvements appear gradually.

Step 2: Find the slow interaction

A standard Lighthouse page-load test cannot capture real interactions, so it reports proxies such as Total Blocking Time. To pin down a slow interaction, record it yourself:

1. Open the page in Chrome and press F12 to open DevTools.
2. Go to the Performance panel and start a recording.
3. Do the thing that feels slow: open the mobile menu, use a filter, tap a form field.
4. Stop the recording and look at the main-thread activity around your interaction. Tasks longer than 50 ms are "long tasks".

Use CPU throttling in the panel's settings to mimic a mid-range phone, because desktop tests flatter almost every site. Panel labels change between Chrome versions, so see Google's DevTools performance documentation if yours looks different.

Tip: Test the same interaction three times. One slow result could be a one-off; a repeated one is your target.

Step 3: Match the symptom to the cause

This table shows the likely cause, the first fix and who is best placed to make it.

Long JavaScript tasks

Scripts, layout and drawing share one main thread. If a script is busy for 300 ms when someone taps, the tap waits. Typical culprits are analytics and tag manager code, A/B testing tools, heavy sliders and mega menus, and framework hydration (the code that makes a server-rendered React or Next.js page interactive).

In the Performance recording, expand the long task in the main-thread flame chart to see which script is responsible. If it is your own code, a developer can break the work into smaller chunks so the browser can paint in between; Google's guide to optimising long tasks covers the techniques. For JavaScript apps, why your React site might be invisible to Google covers rendering choices.

Too many third-party scripts

Live chat, pop-ups, heat maps, review widgets, retargeting pixels, booking tools and social feeds each download, parse and run JavaScript, and many listen for every click. To list them, open DevTools, go to the Network tab, filter by JS and reload. Then:

• Audit first. Note each script's purpose. Do not remove consent, payment, booking or tracking tools without checking what relies on them.
• Remove what nobody uses. Old pixels from past campaigns are common.
• Load on demand. For chat and video, load the heavy script only when the visitor clicks, if your provider documents a delayed mode.
• Consolidate. If four tools do the same analytics job, keep one.
• Use defer carefully. It postpones a script until the HTML is parsed, but the script still takes main-thread time when it runs, and order matters where scripts depend on each other.

Heavy themes and page builders

WordPress and Shopify themes and visual builders often load sliders, animation libraries and icon fonts you never use.

• Look in your builder's settings for options to disable unused widgets or features.
• Check which scripts load on each template, not just the home page.
• On WordPress, deactivate plugins one at a time on a staging copy and retest.
• Avoid stacking several caching or "speed" plugins; they can conflict.

A child theme does not remove the parent theme's scripts by itself. Trimming them usually takes code changes, so brief a developer.

Very large pages

A page with thousands of HTML elements takes longer to update after each interaction. Signs include infinite-scroll pages that slow down as you scroll, and pages that render hundreds of hidden tabs or product variants up front.

• Paginate long lists.
• Load heavy tab or accordion content when opened, but keep text that matters for search in the HTML.
• Animate with CSS transform and opacity rather than width, height or top, which force layout recalculation.

Watch out: Hiding content to speed things up can hurt accessibility and search visibility. Keep important text in the page source.

Slow input handlers

Sometimes the click handler does too much before the screen can update: heavy calculations, or waiting for a server reply before showing anything. Show a pending state immediately, then do the slow work:

button.addEventListener('click', async () => {
  button.disabled = true;
  button.textContent = 'Adding…';   // visible straight away

  try {
    const response = await fetch('/your-add-to-cart-endpoint', {
      method: 'POST'
    });
    if (!response.ok) throw new Error('Request failed');
    button.textContent = 'Added';
  } catch (err) {
    button.textContent = 'Try again';
    button.disabled = false;
  }
});

The endpoint is a placeholder; use your platform's real API. Non-urgent work such as analytics can be pushed back with setTimeout, but never the feedback the visitor is waiting for.

A practical order of work

1. Note the URLs or groups flagged in Search Console.
2. Record the slowest interaction on one of those templates, with throttling on.
3. Identify the biggest offender: your code, a third party, the theme, page size or the handler.
4. Change one thing at a time on a staging copy, after taking a backup.
5. Retest checkout, forms, consent banners and tracking after each change.
6. Re-measure in the lab straight away, then watch field data over the following weeks.

To decide where INP ranks against other problems, see how to read an SEO audit. If images are also slowing your pages, see image optimisation for speed.

One note on tools: Lordevo's free single-page SEO scan checks on-page basics such as titles, descriptions and headings. It does not measure INP, so use it alongside the real-user data above, not instead of it.

Key takeaways

• Judge INP on real-user data and aim for 200 ms or less at the 75th percentile.
• Start with low-risk wins: remove scripts nobody uses, then switch off unused theme and builder features.
• Show visitors feedback immediately, then do slow work afterwards.
• Back up before changes and retest checkout, forms and consent each time.

FAQ

Did INP replace First Input Delay?

Yes, as a Core Web Vital in March 2024. FID only measured the delay before the first interaction; INP considers interactions across the whole visit.

Why does my lab test look fine but Search Console shows a problem?

Lab tests run on one device and connection, often without interactions. Field data covers real visitors on many devices, including older phones.

Does a poor INP mean I will lose rankings?

Core Web Vitals are one part of Google's page experience signals, and great content can still rank with imperfect scores. Treat INP mainly as a usability fix: visitors notice a laggy site whatever search does.