We spent years teaching clients to watch Largest Contentful Paint. Hero images, preload tags, CDN moves: the story was easy to tell in a slide deck. When Interaction to Next Paint became a Core Web Vital in March 2024, most of our accounts already had a green LCP on the homepage. What we had not built was a habit of measuring the clicks that happen after that paint.

Interaction to Next Paint (INP) is a field Core Web Vital about responsiveness across a visit, not a single moment at load. That sounds obvious on paper. In production it meant we were auditing the wrong URLs, trusting the wrong proxies, and celebrating fixes that never touched the menu, the cart step, or the filter drawer where users actually waited.

What we measured before INP (and the gaps we left open)

Our default audit pack looked like a loading problem: homepage, maybe a top landing page, PageSpeed Insights, a Lighthouse export, a note on LCP and Cumulative Layout Shift. First Input Delay had rarely failed on those runs anyway, so "interactivity" felt solved once the main thread cleared the first second.

We skipped, or measured only once:

• Post-load routes on single-page apps (category filters, account areas, checkout steps after the basket).
• Templates shared across dozens of URLs (global nav, consent banner, chat widget) where one slow handler poisons INP on every page that includes it.
• Mobile versus desktop separately, even when the business cared about phone traffic for leads.
• Field data on URLs with modest traffic, because CrUX buckets were thin and lab scores looked reassuring.

None of that is mysterious in hindsight. It is boring portfolio hygiene we had deferred because LCP regressions were louder in client emails.

Where poor INP shows up in production (and why FID looked fine)

The pattern that kept repeating: the first tap after load felt acceptable. The fifth interaction did not. Opening a sticky navigation, applying faceted search, submitting a multi-step form, or hydrating a client-rendered block after an API round trip: those were the gestures INP cares about, and FID never punished us for ignoring them.

Third-party tags were the other recurring villain, but not always on the homepage. A tag manager change on a blog template or a new A/B snippet on checkout could leave INP poor on URLs we had not re-tested because "we already fixed performance last quarter." Shared embeds made it worse: slow interactions inside cross-origin iframes still count toward what users experience, while your own JavaScript cannot inspect the frame. Field data and DevTools frame selection were the only honest witnesses.

We also learned to distrust lab-only confidence. Total Blocking Time during a synthetic load often moved in the same direction as INP problems, but it is not interchangeable. When CrUX said "needs improvement" and Lighthouse looked fine, the argument was almost always JavaScript still busy after the hero painted, not TTFB.

How we monitor INP across client sites today

These are operational choices, not metric definitions. For the 200 ms threshold, interaction phases, and how INP sits next to LCP and CLS, we keep the reference material on the main blog rather than repeating it here:

• Understanding INP: the newest Core Web Vital and why it matters
• LCP, INP, CLS: what each Core Web Vital means and how to fix it

Five INP monitoring habits for agency portfolios

1. We name three to six URLs per client that represent revenue or reputation, not only the homepage. At least one URL must be a post-load journey (checkout, signup flow, logged-in area).
2. We treat INP as field-first. Lab runs still happen before deploys; alerts and client reports lean on field percentiles where CrUX has volume, and on repeated URL-level checks where it does not.
3. We split mobile and desktop in reviews even when stakeholders only ask for "the score." INP on phone traffic has failed while desktop looked fine on the same template more than once.
4. We re-baseline after tag manager releases, framework upgrades, and new client themes, because those changes rarely show up as an LCP regression on the homepage alone.
5. We document which template owns shared chrome (header, footer, consent). When INP moves on many URLs at once, we search there before optimising individual page copy.

For agencies, the portfolio angle matters: one slow pattern in shared JavaScript can drag INP on every property that imports it. That is less visible in a one-off Lighthouse run than in stored history across templates, which is why we layer scheduled tests and budgets onto manual spot checks instead of replacing them.

How to improve INP: an afternoon audit on real user journeys

If you are reading this before your next client QBR, you do not need a new slide on why Interaction to Next Paint exists. You need a short list of interactions real users perform on the URLs you already maintain, and a decision about who owns the alert when field INP slips.

Run this in an afternoon:

• Pick one client site. List five clicks users actually make after the hero loads (not hover, not scroll).
• Open Chrome DevTools Performance, record each path on a mid-tier phone profile, and note which step waits on a long task.
• Compare that list to the URLs in your monitoring tool or spreadsheet. If checkout is not on the list, your governance still thinks performance is a loading problem.

When you are ready to set thresholds and notifications across many sites, treat INP like any other budget metric: agree the number, agree the channel, agree who clears the alert. The guides above walk through fixes once you know which interaction is slow; Google's own long-task and input-delay articles are the right next step after you have a name for the slow gesture.

Next steps for Core Web Vitals responsiveness

We wish we had measured post-load journeys earlier, separated mobile from desktop in reviews, and stopped assuming a healthy first second meant a healthy visit. INP did not create sluggish UIs; it made the ones we had been ignoring visible in Search Console and in client frustration at the same time.

Keep manual traces for the argument in the room. For a portfolio, store field INP on the URLs and templates that matter, re-check after shared script changes, and read the Watcher articles linked above when you need definitions and fix workflows, not another opinion thread about whether responsiveness counts for SEO.