Core Web Vitals INP: why a fast-loading landing page can still lose customers

Fast loading — an optimized hero image, a font that doesn't jump, a first paint under a second — has become second nature for most marketing teams, often covered by the 3-second threshold not to cross. But fast loading doesn't guarantee a responsive page. A visitor can land on a page that paints in 800ms, click the "See the offer" CTA, and wait 400, 600, sometimes 900 milliseconds before anything visibly moves — the time it takes a third-party pixel to fire, an analytics script to load, or an overly heavy React re-render to run. That gap, invisible in most classic speed audits, now has its own official metric: INP.

What INP is, and why it replaced FID in March 2024

Interaction to Next Paint (INP) became an official Google Core Web Vital on March 12, 2024, replacing First Input Delay (FID). The difference matters for a transactional landing page: FID only measured the delay before the very first click of a visit began to be processed — a partial, often flattering signal that ignored everything that happened afterward. INP instead observes every interaction across the entire visit (clicking the CTA, opening a form field, switching an FAQ tab) and retains the latency most representative of the whole set — from the moment the visitor acts to the moment the screen visually reflects the result. A page can have a great FID (the first click responds fast) and a poor INP (the third or fourth click, once third-party scripts have loaded and the main thread is busy, lags noticeably).

The threshold that matters: 200 milliseconds

Google scores INP at the 75th percentile of real visits to a page, across three tiers: under 200ms is rated good; between 200 and 500ms it "needs improvement"; above 500ms it's rated poor. Unlike a lab score (Lighthouse), the official INP is computed from real field data — collected from actual visitors via Chrome (the Chrome User Experience Report, or CrUX) — which means an audit run on an empty page, with no simulated click, will never surface an INP problem even if one genuinely exists under real usage.

Why interactivity affects conversion, not just SEO

INP is a Google ranking factor, but its most direct impact remains behavioral. A study by Ioannis Arapakis, Souneil Park and Martin Pielot presented at CHIIR 2021 (see on Google Scholar) shows that response delays exceeding 7 to 10 seconds on mobile trigger a measurable rise in perceived frustration and fatigue — and that tolerance drops even faster once the interaction repeats without a smooth response. An older but still-cited study by John Hoxmeier and Chris DiCesare presented at AMCIS 2000 (see on Google Scholar) found that a lengthening system response time lowers perceived satisfaction in a near-linear way, well before any full-abandonment threshold. Neither study looks specifically at sales landing pages, but the mechanism they document — frustration rising as the gap between action and visible response widens — is exactly what INP sets out to quantify on today's web.

What tanks INP on a landing page, in practice

• Third-party scripts loaded eagerly — Meta pixel, Google Ads tag, live chat: when they fire on click rather than in the background, they block the main thread at the exact moment the visitor is interacting. See our article on the Meta pixel and Conversions API to run them server-side instead of in the browser.
• JavaScript-animated carousels and sliders, whose event handlers recompute positions on every interaction — often costlier than they look, as detailed in our article on carousels on a landing page.
• Overly heavy form validation, when every keystroke triggers a full field re-validation instead of a targeted check.
• Third-party chat and pop-up widgets that initialize on load and then intercept subsequent clicks while still hydrating.
• Long JavaScript tasks over 50ms that hog the main thread — usually a poorly split bundle rather than a single identifiable culprit function.

How to measure a page's real INP

1. Google Search Console → Core Web Vitals report: the only source that aggregates real field data (CrUX) actually collected from your visitors, by URL and device.
2. PageSpeed Insights: shows both the field score (if traffic is sufficient) and a lab score — useful, but the lab score doesn't simulate a real interaction and can stay overly optimistic.
3. Chrome DevTools' Performance panel, recording a session with a few deliberate interactions (CTA click, opening the FAQ) to visually spot the task blocking the render.
4. Google's web-vitals library, wired into your analytics tool to capture the real INP of every visit, even on traffic still too low to show up in CrUX.

How to improve INP on a Next.js landing page

• Load non-critical third-party scripts with next/script and the strategy="lazyOnload" setting instead of blocking on load — see our guide to deploying Next.js on Vercel.
• Defer initializing third-party chat and tracking widgets until the user's first real interaction (scroll or click), rather than on page mount.
• Split heavy click handlers into shorter tasks (via requestIdleCallback or a simple setTimeout(0) for the non-visual part) so the browser can paint the button's state before finishing the side work.
• Avoid recomputing the entire form state on every keystroke: validate a field on blur (onBlur) rather than on every onChange.
• Keep the number of third-party scripts to the strict minimum — every tool added (heatmap, chat, client-side A/B testing) is a potential source of a long task at the exact moment a visitor is acting.

Mobile: the most common blind spot

The gap between desktop and mobile widens especially on INP: a mid-range smartphone processor often takes three to four times longer than a desktop computer to run the same script. A landing page that shows a good INP measured on a development machine can fall well below the 200ms threshold once tested on the device actually used by most of the ad traffic — see our dedicated article on mobile-first for the full set of levers, beyond INP alone.

Starting from an already clean baseline

The 10 LanderKit templates are built in Next.js with minimal JavaScript by default — no imposed third-party widget, no pre-installed tracking script — which gives a starting point already close to the 200ms threshold before any optimization at all. It's then on you to add your own tools (pixel, chat, A/B testing) while keeping in mind that they run at the exact moment a visitor is about to buy. You can test a template's real behavior before adding anything on the e-commerce demo or the SaaS waitlist demo (€89 each, €229 for the full bundle).