Interaction to Next Paint became a Core Web Vital in March 2024. By November 2026 it is the metric Google Search Console uses to judge whether a page feels responsive. It is also the metric most landing pages still fail.
Not because developers are careless. INP fails because it measures something traditional audits rarely capture. Lighthouse scores, PageSpeed Insights, and WebPageTest waterfalls show load speed. They do not show the delay between a user's click and the browser's next painted frame.
On a landing page that click is usually a hamburger menu, a "Get Started" button, a newsletter signup, or a navigation link. If the browser takes 400 milliseconds to paint the response, the user has already decided the site is broken.
This is the audit I run in 2026 when a landing page's INP exceeds 200 milliseconds on mobile.
What INP Actually Measures
INP observes the latency of every click, tap, and keyboard interaction on a page. It reports the worst interaction delay as the page's score. A good INP is at or below 200 milliseconds. Needs improvement is 200 to 500 ms. Poor is above 500 ms.
INP is not First Input Delay. FID only measured the first interaction after page load. INP measures all interactions. A page with a fast first click but a sluggish fourth click still fails.
INP is not Cumulative Layout Shift. CLS measures visual stability. INP measures responsiveness. A page can have a perfect CLS score and a terrible INP score at the same time.
In Search Console, INP data appears under Core Web Vitals for URLs with enough Chrome User Experience Report traffic. If your landing page is tagged Poor for INP, Google treats it as a page-quality signal.
Why Landing Pages Fail
Landing pages fail INP for three reasons.
First, heavy hero sections. Most marketing sites put a large animated hero above the fold: video backgrounds, canvas particles, staggered text reveals. These animations compete for main-thread time with user interactions. If a user taps Learn more while a CSS animation calculates its next frame, the browser delays the tap response.
Second, component hydration. If your landing page uses React, Next.js, or a similar framework, the HTML arrives from the server. The interactive buttons do not work until JavaScript hydrates. On mobile devices hydration can take 600 to 900 milliseconds. A user who taps during that window experiences an INP failure.
Third, third-party scripts. Analytics pixels, chat widgets, consent banners, and social embeds inject long tasks onto the main thread. One unoptimized script can block interaction for 300 ms or more. On a landing page these scripts often load in the head before your own application code.
The 2026 Audit: Step by Step
Do not guess. Use tools that measure INP directly.
Step 1: Check CrUX Data
Go to Search Console. Open Core Web Vitals. If your landing page URL appears under Poor URLs for INP, you have real-user data confirming the problem. If it does not appear, you do not have enough traffic yet. Run a lab test instead.
Step 2: Run Lighthouse on Mobile
Open Chrome DevTools. Select Lighthouse. Choose Mobile, Simulated slow 4G, 4x CPU slowdown. Run the audit.
Look at the Diagnostics section. Specifically:
Long tasks. Any task over 50 ms is a candidate. If you see tasks over 250 ms during page load, your main thread is congested.
Main-thread breakdown. Look for Scripting taking more than 1 to 2 seconds. That means your JavaScript bundle is too large or hydrating too late.
Interaction to Next Paint. Lighthouse reports a simulated INP. Treat anything above 200 ms as a failure.
Step 3: Use the Long Animation Frames API
Since Chrome 127, the Long Animation Frames API has been available. It tells you exactly which script caused a long frame. Add this to a test page:
if (typeof PerformanceObserver !== 'undefined') {
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.duration > 50) {
console.log('Long frame:', entry.name, entry.duration, 'ms');
console.log('Scripts:', entry.scripts);
}
}
});
observer.observe({ entryTypes: ['long-animation-frame'] });
}Reload your landing page and interact with it. Watch the console. If you see a script you do not recognize taking 120 ms, that is your INP culprit.
Step 4: Test Real Interactions
Lighthouse measures load-time performance. INP measures interactions. Open DevTools. Go to the Performance panel. Record a session. Manually click your hamburger menu, your contact form button, and your navigation links. Look at the Main track. If a click triggers a task over 200 ms, you found an INP failure.
Common Culprits With Code
Culprit 1: Hero Animations Blocking the Main Thread
Bad: A canvas-based particle background running requestAnimationFrame continuously, competing with user taps.
function animate() {
ctx.clearRect(0, 0, canvas.width, canvas.height);
drawParticles();
requestAnimationFrame(animate);
}
requestAnimationFrame(animate);This runs every frame even when the user is trying to click a button.
Better: Use CSS animations. They run on the compositor thread instead of the main thread.
.hero-particles {
animation: float 6s ease-in-out infinite;
will-change: transform;
}
@media (prefers-reduced-motion: reduce) {
.hero-particles {
animation: none;
}
}Culprit 2: Late Hydration in React/Next.js
Bad: Wrapping your entire landing page in a client-only component that hydrates on mount.
export default function LandingPage() {
return (
<ClientOnly>
<Hero />
<Navbar />
<Pricing />
</ClientOnly>
);
}Nothing is interactive until this hydrates.
Better: Use server components for static content. Only hydrate the specific interactive islands that need it.
export default async function LandingPage() {
const pricing = await getPricing();
return (
<>
<Hero />
<Navbar client:load />
<Pricing data={pricing} />
</>
);
}If you use plain Laravel or static HTML, this does not apply. But check that your script tags do not block the parser. Put them at the end of body or use defer.
Culprit 3: Third-Party Consent Banners
A cookie consent banner that injects a 200 KB script and runs layout calculations on every scroll destroys INP on mobile.
Audit: Open the Network tab. Filter by js. Look for scripts from domains you did not write. If a consent banner script is 150 KB and executes on every page load, replace it with a lightweight inline implementation or defer it until the first user interaction.
<!-- Bad: Blocks parser and main thread -->
<script src="https://cdn.consent-provider.com/consent.js"></script>
<!-- Better: Deferred, non-blocking -->
<script src="https://cdn.consent-provider.com/consent.js" defer></script>INP vs. the Other Core Web Vitals
LCP measures when the largest visible element renders. Landing page risk: hero images, web fonts.
CLS measures unexpected layout shifts. Landing page risk: font swaps, injected ads.
INP measures click-to-paint delay. Landing page risk: JavaScript, hydration, third-party scripts.
You can pass LCP and CLS while failing INP. That is the most common 2026 scenario. A page looks fast but feels sluggish when a user tries to interact with it.
The Mobile Problem
Do not audit on your MacBook. Run Lighthouse on a simulated Moto G4 or a real Android device. Mobile CPUs are 4 to 5 times slower than desktop CPUs. A 100 ms script on your laptop becomes a 400 ms task on a mid-range Android phone.
If your mobile INP is 350 ms but your desktop INP is 80 ms, your problem is not your code architecture. It is your JavaScript execution budget. Reduce bundle size, split routes, and defer non-critical scripts.
Final Pre-Publish Checklist
Before you consider a landing page INP-safe, verify:
- Lighthouse mobile INP at or below 200 ms
- No Long Animation Frame entry over 100 ms during user interaction
- Main-thread scripting during load under 1 second
- Third-party scripts deferred or lazy-loaded
- Hero animations use CSS, not JavaScript requestAnimationFrame
- Interactive elements server-rendered or hydrated on demand
- Real-device mobile test passes, not just desktop simulation
If you hit all seven, your landing page is in the top 10% of the web for performance.
Conclusion
If you run a landing-page business, selling templates, themes, or SaaS boilerplates, your customers will eventually ask why their INP scores are poor. The answer is rarely that images are too big. It is almost always main-thread congestion from JavaScript, third-party scripts, or unoptimized hydration.
Audit your own templates first. If your demo pages fail INP, your customers' pages will too.
