Core Web Vitals INP: test the click that earns the sale

Core Web Vitals INP should be tested on the click, tap or keypress that moves a buyer closer to the sale, not on a homepage score polished in isolation.

A site owner can open PageSpeed Insights, see a Lighthouse performance score of 99, and still find “Core Web Vitals Assessment: Failed” above it. Both results can be true. One is a controlled test. The other describes real Chrome users over time.

That difference matters when the slow action is not on the homepage. It might be the service accordion that reveals the answer, the date picker that starts a booking, or the form button that turns interest into an enquiry.

TL;DR: Start with field data, find the affected sales route, and identify the exact interaction on mobile. A good INP is 200 milliseconds or less at the 75th percentile. Use a lab test to reproduce the delay, then give the fix a page, action, owner and retest date.

What Core Web Vitals INP actually measures

Interaction to Next Paint measures how quickly a page gives visual feedback after a qualifying interaction. It observes clicks, taps and keyboard input throughout a visit. It then reports the longest interaction, or close to the longest on pages with many interactions.

The clock covers three parts:

1. Input delay: the browser is busy before it can run the interaction.
2. Processing time: the event handler does the work triggered by the action.
3. Presentation delay: the browser calculates and paints the visual update.

According to the current web.dev guidance, an INP of 200 milliseconds or less is good at the 75th percentile. More than 500 milliseconds is poor. The range between them needs improvement.

This is not the same as measuring how fast the page first appears. A service page can load quickly, look complete and still hesitate when somebody opens a comparison table. A booking page can show the calendar promptly, then freeze when the visitor selects a date.

Scrolling itself does not count as an INP interaction. A tap, click or keypress during a scroll can count, and other work on the main thread can still delay what the browser paints next. This is why staring at the clicked button's code can miss the real cause.

Why a 99 Lighthouse score can still fail INP

The apparent contradiction comes from two different kinds of evidence.

Lighthouse creates lab data. It loads a page under controlled conditions and runs a repeatable test. That makes it useful for finding technical causes, comparing changes and reproducing a problem.

The Chrome User Experience Report, commonly called CrUX, creates field data from eligible real Chrome visits. Core Web Vitals field reports use a rolling 28-day window and assess the 75th percentile. Devices, networks, routes and user behaviour vary.

So a fast lab run today does not erase slow interactions experienced by real users during the previous four weeks. Nor does a red field report tell you exactly which interaction needs work.

Use the two sources in sequence:

1. Field data sets the priority. It tells you whether real visitors have a recurring problem.
2. Lab data helps diagnose it. It gives a developer a controlled place to reproduce and inspect the delay.
3. New field data confirms the outcome. It shows whether the change survives real devices and real behaviour.

Do not ask which tool is “right” until you have checked whether they are answering the same question. Often they are not.

Which page should you test first?

Start with the route closest to an enquiry or sale, not whichever URL happens to be prefilled in PageSpeed Insights.

The 2025 HTTP Archive Web Almanac found that 80% of mobile homepages had good INP, compared with 69% of mobile secondary pages. That is an 11 percentage point gap.

Secondary pages carry more working parts. A service page might contain expandable sections, price selectors, comparison tables and embedded reviews. A booking route might combine a calendar, form validation, analytics tags and a chat widget. Those are the interactions that help a buyer decide or act.

Walk the mobile sales route as a customer would:

• Open the service page from search.
• Reveal the proof or answer that reduces risk.
• Change an option or select a date.
• Complete the form.
• Check the confirmation state.

Record every moment when the interface does not respond immediately. You are not proving poor INP with a subjective tap test. You are building a shortlist of commercially important actions to match against field evidence.

If the booking button waits 600 milliseconds, a 99 beside your homepage is just the wrong screenshot.

This is also why a conversion-first website should be treated as a route, not a collection of attractive pages. The route must help the visitor understand, trust and act without avoidable delay.

How to find the interaction causing poor INP

Search Console and the CrUX section in PageSpeed Insights are the starting point. They tell you whether real-user INP is good, needs improvement or is poor. They may also group similar URLs.

They often cannot name the exact click.

For that, use Real User Monitoring that captures interaction detail. The useful record is not “INP is red”. It is:

• the page URL or template;
• the element the visitor used;
• whether it was a click, tap or keypress;
• the latency and device class;
• the time spent in input delay, processing and presentation;
• the browser and route context where available.

Now rank those records by business value. A slow tap on decorative text and a slow tap on “Choose this plan” can have the same latency. They do not deserve the same priority.

Take the highest-intent recurring interaction into a lab session. Repeat the same route on a representative mobile setup. Use browser performance tools to inspect long tasks, event handlers, rendering work and third-party scripts around that moment.

The order matters. If you begin in the lab without field context, you can spend hours improving an interaction nobody uses. If you stop at field data, you can prove a problem exists but not tell a developer where to look.

For a lower-traffic site with no URL-level field data, start with origin-level data if it is available. Then use your own real-user monitoring or a careful route test across several ordinary mobile devices. The absence of CrUX data is not proof that the page is fast or slow. It means the public dataset does not have enough eligible visits to report that view.

What usually makes a sales interaction slow?

The clicked element is not always guilty.

Imagine a visitor tapping “Check availability”. The browser might first finish a long analytics task. The button's event handler might then validate several fields, update application state and request available dates. Finally, a large part of the page might re-render before the visitor sees a response.

The delay belongs to different owners depending on the phase.

A long input delay often points to main-thread work already in progress. Third-party scripts, tag managers, chat widgets and large JavaScript tasks deserve inspection.

Long processing time points towards the work triggered by the interaction. The handler may be doing too much at once, repeating calculations or updating more state than necessary.

A long presentation delay points towards rendering. The page may be recalculating a complex layout or painting a large visual change before it can show feedback.

The practical fixes vary:

• break long work into smaller tasks;
• move non-essential work until after the visual response;
• reduce the amount of interface that changes;
• remove or delay a third-party script;
• simplify the component or form logic;
• show immediate feedback while the heavier work continues.

There is a business trade-off here. The chat widget, tracking script or animated selector may have an internal champion. If it delays the primary buyer action, keeping it unchanged is still a decision. Make that decision against the route's purpose, not the feature owner's preference.

What should an INP fix brief contain?

A performance report is not a work brief.

The person approving the work should be able to read one page and know what will change. Use this structure:

1. Page: the affected URL or template.
2. Action: the exact click, tap or keypress.
3. Evidence: field INP at the 75th percentile, device class and observation window.
4. Reproduction: the lab steps that trigger a comparable delay.
5. Cause: input delay, processing, presentation, or a measured combination.
6. Change: the script, handler, component or rendering work to alter.
7. Owner: one person responsible for making and explaining the change.
8. Retest: the same interaction in the lab now, then field evidence after enough new visits.

Add a short acceptance condition. For example: “On the mobile booking route, selecting an available date shows visual feedback within 200 milliseconds in the representative lab test, with field INP returning to good at the 75th percentile.”

The field result will not update on the day the code changes because the public dataset covers a rolling period. Keep the immediate lab evidence and note when the field view will be reviewed again.

This kind of decision trail is what an operating system for marketing should preserve. SharpOS keeps the brief, owner, approval and evidence connected, so the result is not reduced to a green screenshot with no explanation.

When should you stop optimising INP?

Stop when the important route is responsive, the field evidence is good, and the next round of work has a weaker business case than something else on the site.

Across the 2025 HTTP Archive dataset, 77% of mobile origins and 97% of desktop origins had good INP. The metric matters, but not every site needs an open-ended performance programme.

Google says Core Web Vitals are used by its ranking systems. It also says a good result “doesn't guarantee that your pages will rank at the top”. Treat INP as one part of page experience, not an SEO promise.

Do not commission more work just because one lab score could move from 95 to 100. Continue only when real users still experience delay on a meaningful action, or when the remaining technical issue creates a wider reliability or accessibility risk.

For some sites, the right answer is a small fix and a scheduled check. For others, repeated problems reveal a page or stack that needs deeper work. The scope should follow the evidence. SharpHaw plans are structured around that kind of owned, iterative work rather than an endless score chase.

Core Web Vitals INP FAQ

What is a good INP score?

A good INP is 200 milliseconds or less at the 75th percentile. Between 200 and 500 milliseconds needs improvement. More than 500 milliseconds is poor.

Why does Lighthouse pass while Core Web Vitals fail?

Lighthouse is a controlled lab test. The Core Web Vitals assessment uses real-user field data over a rolling 28-day period. A good run in the lab can coexist with slower interactions across real devices, routes and users.

Does scrolling affect INP?

Scrolling itself is not one of the qualifying INP interactions. Clicks, taps and keyboard input are. Main-thread work connected with the page can still delay the next qualifying interaction.

What if PageSpeed Insights has no field data?

Check whether origin-level data is available. If not, collect your own real-user interaction data or test the complete buyer route across representative mobile devices. No public field data means the dataset is insufficient, not that the page automatically passes.

Is INP a Google ranking factor?

Core Web Vitals are used by Google's ranking systems as part of page experience. A good INP does not guarantee a ranking position, and a weak page will not become useful merely because its responsiveness metric passes.

The useful outcome is not a perfect screenshot. It is a buyer action that responds, evidence that explains the change, and one person who owns the next check.

Plan. Build. Iterate.

Book a 30-min call — bring your worst-performing page, leave with a fix-it list.