INP and Core Web Vitals: why website checks should not stop at load time

Many website checks still stop where the page looks loaded. That was always a little optimistic. Since Interaction to Next Paint, or INP, became relevant as a Core Web Vitals metric, it is also practically too narrow.

Users do not judge a website only by whether the hero section eventually appears. They click menus, open filters, submit forms, accept or reject cookies, switch tabs, start videos, or use a checkout. If those interactions respond slowly, the site feels broken — even if the Lighthouse score looks friendly on paper.

What INP measures

INP measures responsiveness across interactions such as clicks, taps, and keyboard input. web.dev describes INP as a metric that observes the latency of user interactions throughout the page lifecycle and reports a value intended to represent overall responsiveness. As a practical threshold, web.dev says up to 200 ms is good, above 200 to 500 ms needs improvement, and above 500 ms is poor.

Google introduced INP as the successor to First Input Delay. The important difference is that FID only looked at the first interaction. INP looks more broadly at real interactivity. For modern websites, that is more realistic because the problem is often not the first click, but later UI states: cookie banners, filter lists, form validation, modals, booking flows, or JavaScript widgets.

Why small websites should care

INP may sound like performance-nerd territory. In reality, it hits very normal website projects:

• A WordPress theme ships too much JavaScript.
• A page builder creates large DOM structures.
• A cookie banner blocks the main thread.
• Tracking scripts run on every page.
• A form validates too much in the browser.
• A shop filter rerenders hundreds of elements.
• A chat widget attaches itself to every interaction.

The result: the page may load acceptably, but feel heavy and sluggish. That is where business damage starts: fewer inquiries, more drop-offs, worse mobile experience, and annoyed users.

What an INP check should cover

A useful website check should not only look at the homepage and load time. For INP, real interactions matter:

1. Test the cookie banner: open it, reject, accept, save settings.
2. Check navigation: mobile menus, dropdowns, tabs, and accordions.
3. Test forms: input, validation, error messages, submission.
4. Walk through conversion flows: inquiry, checkout, booking, login, or newsletter signup.
5. Watch third parties: analytics, pixels, chat, maps, videos, consent tools.
6. Take mobile seriously: weaker devices reveal problems earlier than a developer laptop.
7. Separate field and lab data: PageSpeed Insights, CrUX, and RUM answer different questions.

The key point: a lab test without interaction can miss INP problems. If nobody clicks, taps, or types, you do not see where the website actually gets sticky.

Typical technical causes

Poor INP is often not one monster bug. It is usually the sum of many small decisions: large JavaScript bundles, long tasks on the main thread, unnecessary rerenders, complex layout calculations, too many event listeners, uncontrolled third-party scripts, overloaded tag managers, or animations that ignore weaker devices.

For Website-Pflichtencheck, the question is therefore not only: Is the page fast? The better question is: which interactions feel slow for real users, and which scripts or components cause that?

Mini checklist for website teams

Small teams can start with a repeatable process:

• Check PageSpeed Insights for important URLs once per quarter.
• Retest after relaunches and major plugin or tracking changes.
• Click through mobile user flows deliberately, not only desktop.
• Test consent, form, and checkout flows separately.
• Document suspicious third-party scripts.
• Regularly remove unused scripts and JavaScript bloat.
• Consider real user monitoring for critical pages.

This is not performance mysticism. It is maintenance. A website that visually loads but freezes on every interaction is not almost done. It is done testing its users’ patience.

Conclusion

INP shifts the question from "how fast does something appear?" to "how reliably does the website respond?". For website owners, agencies, and dev teams, that is useful because it is closer to real usage.

A good website check should therefore look at loading, stability, and interactivity together. Core Web Vitals are not an end in themselves. They are an early warning system for the places where users leave before they can even explain why the site feels bad.

Sources

• Google Search Central: Introducing INP to Core Web Vitals
• Google Search Central: Understanding Core Web Vitals and Google search results
• web.dev: Interaction to Next Paint (INP)

Note: This article is a technical overview and does not constitute legal advice.