Motta Industries Blog

You tap “Add to cart.” Nothing happens. You tap again. A moment later the page jumps, and now there are two items in your cart. Most people have had that experience, and most have quietly decided something about the business behind the page.

Since March 2024, that kind of delay has a name in Google’s performance vocabulary. Interaction to Next Paint, usually shortened to INP, is now one of the Core Web Vitals, the small set of measurements Google uses to describe real-world page experience. This article explains what INP measures, why it replaced an older metric, what a “good” score looks like, and what a small business can sensibly do about it.

What INP actually measures

Most speed discussions focus on loading: how long it takes for a page to appear. INP is about something different. It looks at what happens after the page has loaded, when someone tries to use it.

Every time a visitor clicks, taps or presses a key, the browser has to run whatever code responds to that action and then draw the result on the screen. INP looks at how long that takes across a visit. If a menu opens instantly, a form field accepts typing smoothly and a button responds right away, the page has good responsiveness. If the screen freezes for a moment after each tap, it does not.

In plain terms, INP answers the question customers ask without thinking about it: when I do something on this page, does it respond?

Why Google replaced First Input Delay

Before INP, the responsiveness measure in Core Web Vitals was First Input Delay, or FID. As its name suggests, FID looked only at the first interaction on a page, and only at part of the delay involved.

When Google’s Search Central team introduced INP to Core Web Vitals in May 2023, it noted that FID had known limitations. The Chrome team had announced INP in 2022 as an experimental metric and tested it with the community for another year before deciding to promote it. The post said INP would replace FID as the Core Web Vitals responsiveness metric in March 2024, and that the Search Console report would switch over at that point.

In January 2024, the Chrome team confirmed the date. Its post explaining that INP would become a Core Web Vital on March 12 described how INP had started as an experimental metric in May 2022, became a pending metric the following year, and would replace FID on that date, with FID being deprecated.

On March 12, 2024, the Chrome team published its announcement that INP is officially a Core Web Vital, replacing FID. Tools such as PageSpeed Insights now evaluate INP instead of FID in their Core Web Vitals assessment.

What counts as a good score

According to the Chrome team’s launch post, at least 75% of INP experiences should respond to user input in under 200 milliseconds for a page to be considered good. That is a fraction of a second, but people notice the difference between an instant response and a noticeable pause.

The 75% figure matters. Core Web Vitals are scored based on how pages perform for real visitors in the field, at the 75th percentile, as the January 2024 post explains. That means a site cannot pass simply because it feels fast on the owner’s new laptop. It has to respond quickly for most real visitors, including people on older phones and slower connections.

What INP means for search

It is natural to ask whether INP will change your rankings. Google’s May 2023 post was careful here. It said Google highly recommends that site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally. It also said that great page experience involves more than Core Web Vitals, and that good scores in Search Console or third-party reports do not guarantee good rankings.

The practical reading is that INP is one signal among many. A sluggish page is unlikely to be rescued by good content alone, and a responsive page will not outrank better answers on speed alone. The stronger reason to care is the customer on the other end of the tap.

Why a slow button costs more than seconds

Responsiveness problems tend to appear exactly where they hurt most: on the pages where people take action. Think about:

• Add to cart and checkout buttons that do not react, leading to double taps, duplicate orders or abandoned purchases.
• Booking calendars that freeze while loading availability.
• Menus and filters that lag, so visitors are unsure whether their selection registered.
• Forms where typing feels delayed, especially on phones.
• Pop-ups and chat widgets that block interaction while they load.

Each of these sends a message about the business. A delay at the moment of commitment can feel like unreliability, even if the products or services are excellent. The January 2024 post pointed to published case studies, including from The Economic Times and redBus, on how reducing interaction latency improved business outcomes, and suggested optimizing INP may help other sites achieve their goals as well.

How to check your site

You do not need to be a developer to get a first look. The Chrome team’s posts suggest a few starting points:

PageSpeed Insights. Enter a page address and see whether field data from the Chrome User Experience Report, known as CrUX, is available. If it is, the report shows how real visitors experience INP on that page.

Search Console. If your site is verified, the Core Web Vitals report groups pages with similar issues and shows whether INP is rated good, needs improvement or poor.

Your analytics or monitoring provider. The January 2024 post notes that real user monitoring providers may also collect field data, and suggests asking whether yours supports INP.

Two caveats are worth knowing. Smaller sites may not have enough traffic to be included in CrUX, which has eligibility criteria. And numbers from different tools may not match exactly, because they measure different visitors in different ways.

What changed in the tools

The switch affected the tools site owners rely on. According to the January 2024 post, FID was removed from Search Console as soon as INP became a Core Web Vital, while other tools such as PageSpeed Insights and CrUX offered a six-month deprecation period. The launch post set September 9, 2024 as the date by which applications using FID data from the CrUX or PageSpeed Insights APIs needed to move to INP. If an agency or plugin produces performance reports for you, it is worth confirming that those reports now show INP rather than FID, so you are not tracking a retired number.

What usually causes poor INP

The Chrome team’s guidance points to a handful of common causes. You do not need to understand the code to recognize the patterns:

Long-running JavaScript. When the browser is busy running a large block of script, it cannot respond to a tap until it finishes. The launch post recommends avoiding or breaking up long-running JavaScript.

Unnecessary JavaScript. Many sites load scripts they no longer need: old tracking codes, unused plugins, features nobody uses. Each one competes for the browser’s attention. The advice is simply to avoid scripts that are not needed.

Large rendering updates. If a single tap causes the page to redraw a large part of the screen, the response takes longer. The guidance recommends avoiding large rendering updates.

Very large or complex pages. The January 2024 post notes that large page structures can require a lot of rendering work, and that complex layouts and styling rules can add to the work done after each interaction.

Heavy client-side rendering. Sites that build much of their content in the browser with JavaScript may face extra interactivity challenges.

For small businesses, the most common real-world culprits tend to be page builders loading many features on every page, multiple third-party widgets, and plugins added over time and never removed.

A practical plan for small businesses

The launch post describes a general workflow that translates well for non-developers:

1. Look at real-user data first. Check PageSpeed Insights or Search Console for your most important pages, such as the home page, key service pages, booking and checkout.
2. Identify the slow interactions. Note which actions feel sluggish on an ordinary phone: opening the menu, choosing a date, adding to cart.
3. Reproduce and diagnose. A developer can use browser tools to see exactly what code runs after a slow tap.
4. Reduce the work. Remove unused plugins and scripts, delay non-essential widgets, and simplify heavy components.
5. Measure again. Field data takes time to reflect changes, so check back over the following weeks and keep monitoring.

Hosting matters too. A slow server mainly affects loading, but an overloaded or outdated environment can make everything feel slower. Reliable web hosting is part of the foundation, even though INP is mostly about what happens in the browser.

Mobile is where INP problems show up

Phones generally have less processing power than desktop computers, so the same script that runs smoothly on a desktop can cause noticeable delays on a mid-range phone. Testing on a real, ordinary phone, not just the newest model, is one of the most useful things a business owner can do. Try key actions on mobile data rather than Wi-Fi, and notice any pause between tap and response. Sites built with responsive designs that serve lighter layouts and fewer heavy features on small screens tend to have an easier time.

If your site already scored well on FID

Google’s May 2023 post offered some reassurance: improvements made for FID are a good foundation for improving INP. If you have already worked on page performance, you are not starting from zero. INP is stricter because it looks across the whole visit rather than just the first interaction, so pages that passed FID may still need attention.

Questions to ask your developer

• Which of our key pages have INP data, and what does it show?
• Which interactions are slowest, and what code runs when they happen?
• Which plugins, scripts and widgets can we remove or delay?
• How will we monitor INP after changes and future updates?
• Will new features, such as a booking widget or chat tool, be tested for responsiveness before launch?

The bottom line

INP measures something every customer feels: whether a page responds when they try to use it. It replaced First Input Delay as a Core Web Vital on March 12, 2024, and a good score means most real interactions respond in under 200 milliseconds. It is one signal among many for search, but a strong one for customer trust.

If your buttons, menus or booking tools feel sluggish, Motta Industries’ web development team can diagnose the slow interactions and streamline the code behind them.