Most advice on this subject picks one of two meanings and ignores the other, which is why following it tends to backfire.
“Interactivity” means two different things. To a designer it means the parts of a page that respond to people: quizzes, calculators, filters, configurators, hover states. To Google it means a measurable number, Interaction to Next Paint, which records how quickly your page reacts when someone taps or clicks.
The two pull against each other. Nearly every interactive element you add is JavaScript, and JavaScript is what makes INP worse. A site can be full of interactive features and feel broken, which is worse than a plain page that works. So the useful question is not how to add interactivity. It is how to add the interactivity that earns its weight, and keep the page responsive while doing it.
What is website interactivity?
Two definitions, both valid, and worth separating before you brief anyone.
Interactivity as responsiveness. How fast the page reacts to input. This is what Google measures and what users feel as quality. A button that visibly responds in 100 milliseconds feels instant. At 500 milliseconds it feels broken, and people tap it again.
Interactivity as participation. Elements that let someone do something rather than only read: filter a product list, estimate a cost, configure an option, check eligibility.
The second is worthless without the first. An interactive pricing calculator that takes two seconds to respond to each input is actively worse for you than a static price table, because it creates an expectation and then fails it.
How Google measures interactivity: INP
Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024. The difference matters: FID only measured the delay before processing began on the first interaction. INP measures the full round trip, on interactions throughout the visit.
|
INP at the 75th percentile |
Rating |
|
200ms or less |
Good |
|
200ms to 500ms |
Needs improvement |
|
Over 500ms |
Poor |
Two details people miss.
It is measured at the 75th percentile of real visits, not an average. So a page can feel fine on your laptop and fail, because the measurement is dominated by mid-range Android phones on ordinary connections.
It covers every interaction, not the first. A fast-loading page with a sluggish filter still fails.
Here is the part that reframes the whole problem. INP is the Core Web Vital most sites already pass. In the May 2026 Chrome User Experience Report release, 86.6% of origins passed INP, against only 55.9% passing all three Core Web Vitals together.
But the aggregate hides where the failures sit:
|
Device |
Origins passing INP (CrUX, May 2026) |
|
Desktop |
97.9% |
|
Mobile |
82.5% |
A fifteen-point gap. So INP is not a widespread problem, it is a mobile problem, and it is the metric your laptop is least likely to reveal. If you fail INP, you almost certainly fail it on a mid-range Android phone while everything looks fine in the office.
For context on the other two metrics, see Core Web Vitals explained.
Why INP breaks, in three parts
An interaction has three phases. Knowing which one is yours saves you from fixing the wrong thing.
|
Phase |
What happens |
Typical cause of delay |
|
Input delay |
The browser waits for the main thread to free up before your handler can run |
Scripts already executing: analytics, tag managers, third-party widgets |
|
Processing time |
Your event handler runs |
Heavy work in the handler, large loops, synchronous layout reads |
|
Presentation delay |
The browser paints the result |
Large DOM, expensive layout, animating properties that force reflow |
Input delay is the most common, and it is usually not your own code. It is the fourth analytics tag, the chat widget, the heatmap tool, the consent banner, all competing for the same thread.
Processing time is your code, and the usual culprit is doing everything at once instead of doing the visible part first.
Presentation delay is layout cost, often from animating the wrong CSS properties or rendering a very large list.
Fix the input delay first
This is where most sites recover the most milliseconds for the least work.
Count your third-party scripts. Open the network tab and list every script you did not write. Most sites find at least one nobody can account for. Each one competes for the main thread on every interaction.
Remove before optimising. A tag with no owner and no report attached to it should go. This is a conversation with marketing, not with developers, and it is usually the single highest-return action available.
Defer what can wait. Chat widgets, review widgets and heatmap tools rarely need to load before first interaction. Load them on idle, or on first scroll, or on a click of a lightweight placeholder.
Consolidate tag managers. One container, audited quarterly. Tag managers accumulate because adding is easy and removing requires someone to decide.
Our website performance audit covers the full inventory process.
Fix your own handlers
Yield to the main thread. If a handler does substantial work, break it up so the browser can paint between chunks. Update what the user needs to see, yield, then finish the rest.
button.addEventListener(‘click’, async () => {
showImmediateFeedback(); // paint something now
await new Promise(r => setTimeout(r, 0)); // let the browser breathe
doTheExpensiveWork(); // then the rest
});
That pattern alone fixes a surprising number of INP failures, because the user’s perception is set by the first paint, not by when the work finishes.
Give feedback before you have an answer. A pressed state, a spinner, a disabled button. The interaction then reads as acknowledged even while work continues. Doing nothing for 400 milliseconds reads as a broken button.
Debounce input handlers. A search field firing on every keystroke does far more work than one firing 200 milliseconds after typing stops.
Animate only transform and opacity. Animating width, height, top or left forces layout on every frame. Transform and opacity are composited and much cheaper.
Which interactive elements are actually worth the weight
This is the part design articles skip. Interactivity has a cost, so it should do a job.
|
Element |
What it does for you |
Cost |
|
Product or service filters |
Removes the main reason people leave a list page |
Moderate, can be server-rendered |
|
Cost or quote estimator |
Qualifies leads and answers the question that otherwise triggers a phone call |
Moderate |
|
Eligibility or fit checker |
Pre-qualifies and reduces unsuitable enquiries |
Low to moderate |
|
Comparison table with toggles |
Helps a decision that is genuinely multi-variable |
Low |
|
Multi-step form with progress |
Raises completion on long forms |
Low |
|
Configurator with live price |
Converts considered purchases |
High |
|
Micro-interactions and states |
Makes the whole site feel responsive |
Very low |
And the ones that rarely justify themselves, said plainly because somebody has probably pitched you one:
- Scroll-triggered animation sequences. Heavy, often cause layout shift, and almost never change a decision.
- Parallax. A 2013 effect with a 2026 performance bill.
- Custom cursors. Break on touch, which is most of your traffic.
- Preloader animations. You added time to make the wait look intentional.
- Quizzes with no segmentation behind them. If the answers do not change what the visitor is shown or what your sales team knows, it is a toy.
- Full-page scroll hijacking. Breaks the one interaction every user already understands.
The test is simple: does it help someone decide, or help you qualify them? If neither, it is decoration with a performance cost.
The cheapest interactivity is CSS
A large share of what makes a site feel responsive needs no JavaScript at all, and therefore costs nothing in INP.
Hover and focus states on everything clickable. Active and pressed states on buttons. <details> and <summary> for accordions, which are native, accessible and free. CSS transitions on state changes. Visible focus rings for keyboard users. Smooth scroll-behavior. Inline validation styling via :invalid and :user-invalid.
Build in that order: native HTML first, CSS for state and motion, JavaScript only for what genuinely cannot be done otherwise. A site built this way feels more responsive than one carrying a framework to produce an accordion.
Forms are your most-used interactive element
On most business sites the form is the interaction that matters, and it is usually the least considered.
What raises completion:
- Inline validation on blur, not on submit. Tell someone the postal code is wrong when they leave the field, not after they have filled in nine more.
- Errors next to the field, in words, never only in red.
- Never clear the form on error. This still happens and it is the fastest way to lose a submission.
- Correct input types, so mobile keyboards match: type=”email”, type=”tel”, inputmode=”numeric”.
- Autocomplete attributes, so browsers can fill fields.
- A labelled submit state. Disable it, change the text, and prevent double submission.
- Fewer fields. Every optional field costs completions. If your team does not use the answer, delete the field.
See UX design best practices for the wider pattern set, and how to increase your website conversion rate for what these changes are worth.
How to measure it properly
Field data is the only data that counts for ranking. INP is scored from real visits via the Chrome User Experience Report. Your laptop is not the measurement.
- PageSpeed Insights shows field data at the top and lab data below. Read the top half.
- Search Console’s Core Web Vitals report groups URLs by status, which is where you find patterns rather than single pages.
- The web-vitals JavaScript library reports INP from your own visitors, with attribution showing which element and which phase caused the worst interactions. This is the one that tells you what to fix.
- Chrome DevTools Performance panel, with CPU throttled to 4x and network to Fast 3G, reproduces the conditions your 75th percentile actually experiences.
Measure before and after, on the same pages, over at least 28 days. CrUX data is a rolling window, so changes take weeks to appear.
Interactivity that excludes people is not interactivity
Anything interactive needs to work without a mouse.
Keyboard operable, with a visible focus state. Focus moved deliberately when a modal opens and returned when it closes. Escape closes things. Dynamic content changes announced to screen readers. No interaction that depends on hover alone, since touch devices have no hover.
Custom-built interactive components are where this breaks most often, which is another argument for native HTML wherever it will do the job. See UX design in web development and UI vs UX for how these responsibilities split.
A practical order of work
- Measure INP from field data and identify the worst pages.
- Inventory third-party scripts and remove anything with no owner.
- Defer what does not need to load before first interaction.
- Add immediate visual feedback to every interactive element.
- Replace JavaScript components with native HTML and CSS where possible.
- Fix your forms.
- Only then consider adding a new interactive feature.
- Re-measure after 28 days.
Most sites gain more from steps two to six than from anything they could add.
Common mistakes
- Adding features before fixing responsiveness. The new feature inherits the problem.
- Testing on a fast laptop. INP is scored at the 75th percentile of real devices.
- Treating INP as a load-time metric. It measures interactions, not loading.
- Animating layout properties instead of transform and opacity.
- Building accordions and tabs in JavaScript when HTML provides them.
- Judging a fix in a week. CrUX uses a rolling window.
- Confusing motion with interactivity. An animation plays at you; an interaction responds to you.
Frequently asked questions
What is website interactivity?
It has two meanings. Technically it is how quickly a page responds to input, measured by Interaction to Next Paint. In design terms it is the elements that let visitors do something rather than only read, such as filters, calculators and configurators. The second depends on the first, because an unresponsive interactive element is worse than a static one.
What is a good INP score?
200 milliseconds or less at the 75th percentile of real visits. Between 200 and 500 needs improvement, and above 500 is poor. It is measured across all interactions during a visit, not just the first.
How do I improve INP?
Work through the three phases in order. Reduce input delay by removing and deferring third-party scripts. Reduce processing time by yielding to the main thread and giving immediate visual feedback before expensive work finishes. Reduce presentation delay by animating only transform and opacity and avoiding very large DOM updates.
Does adding interactive elements hurt SEO?
It can, indirectly, if the elements are built in JavaScript that delays interaction and pushes INP above 200 milliseconds. Core Web Vitals are a ranking signal. Interactive elements built with native HTML and CSS carry almost no cost.
What replaced First Input Delay?
Interaction to Next Paint, in March 2024. FID measured only the delay before the first interaction’s handler started. INP measures the full interaction, including processing and painting, across the whole visit.
Which interactive elements are worth adding?
The ones that help someone decide or help you qualify them: filters on list pages, cost estimators, eligibility checkers, multi-step forms with progress. Scroll animations, parallax, custom cursors and preloaders generally cost performance without changing outcomes.
How do I make a website feel interactive without JavaScript?
Hover, focus and active states on everything clickable, CSS transitions on state changes, native <details> elements for accordions, visible focus rings, and inline validation styling with :invalid. This covers most of what makes a site feel responsive, at no cost to INP.
How long before INP improvements show in Search Console?
Allow at least 28 days. Core Web Vitals field data comes from a rolling window of real visits, so changes appear gradually rather than immediately.
Where this usually lands
For most business sites the honest finding is that the site does not need more interactivity. It needs the interactions it already has to respond properly, and it needs two or three unaccounted-for third-party scripts removed.
That is a less exciting brief than a new configurator, and it is usually worth more.
If you want someone to measure it and work through the order above, that is part of our UI and UX web design service. If the underlying problem is speed rather than interaction, start with website speed optimisation. And if you are not sure which it is, a website performance audit answers that first.
