43% of Sites Fail INP - PageSpeed Won't Tell You Why

By Jordan Hauge — Published February 25, 2026 — Category: Performance, Core Web Vitals

Interaction to Next Paint (INP) is the most commonly failed Core Web Vital in 2026, affecting 43% of websites. PageSpeed Insights shows you lab data with Total Blocking Time, but INP is measured in field data from real users. Most sites think they're fine because their lab scores look good, but they're bleeding conversions due to poor real-world responsiveness. Here's what PageSpeed won't tell you and how to actually fix it.

Google replaced First Input Delay with Interaction to Next Paint in March 2024. Two years later, 43% of websites still fail the 200-millisecond threshold. That makes INP the most commonly failed Core Web Vital across the web.Most of those sites have no idea they're failing.They run PageSpeed Insights, see a decent performance score, maybe even hit 90+, and assume everything is fine. But PageSpeed's lab data doesn't measure INP. It measures Total Blocking Time, which is a different metric entirely. Your lab score can be perfect while your real users are experiencing slow, frustrating interactions that tank your conversion rates.The gap between what PageSpeed shows you and what Google uses for rankings is costing you traffic and revenue. Let me show you why.What PageSpeed Insights Actually Measures (And What It Doesn't)PageSpeed Insights gives you two types of data: lab data and field data.Lab data comes from Lighthouse running a simulated test on a single device with predefined network conditions. It's consistent, reproducible, and useful for debugging. But it's not what real users experience.Field data comes from the Chrome User Experience Report (CrUX), which collects anonymized performance metrics from actual Chrome users over a 28-day period. This is what Google uses for search rankings. This is what determines if you pass Core Web Vitals.Here's the problem: INP only exists in field data. The lab equivalent is Total Blocking Time (TBT), which measures something different.TBT measures the total time the main thread is blocked during page load. INP measures the latency of every user interaction throughout the entire session and reports the worst one at the 75th percentile.A site can have 0ms TBT in the lab and still fail INP in the field because users are interacting with elements that weren't tested in the synthetic environment.Most developers optimize for what they can see in PageSpeed's lab results. They reduce TBT, improve the performance score, and move on. Meanwhile, their real users are experiencing 300ms delays when clicking buttons, opening menus, or submitting forms.Why INP Replaced FID (And Why It's Harder to Pass)First Input Delay (FID) only measured the delay before the browser could start processing the very first interaction on a page. If that first click was fast, you passed FID regardless of what happened afterward.INP captures every interaction. Every click, tap, and key press throughout the user's entire visit. It reports the worst interaction at the 75th percentile, making it far more representative of actual user experience.When Google made the switch in March 2024, nearly 600,000 websites went from passing to failing Core Web Vitals overnight. Sites that had been coasting on good FID scores suddenly faced a much harder test.The transition caused roughly a 5 percentage point drop in mobile Core Web Vitals pass rates according to the HTTP Archive Web Almanac 2024. This happened because many sites that appeared responsive under FID had slow later interactions that INP now captures.Two years later, the pass rate has barely recovered. Based on Chrome User Experience Report data as of early 2026, INP remains the most commonly failed Core Web Vital. LCP has a higher pass rate because image preloading and CDN optimization are well-understood fixes.CLS has the highest pass rate because adding explicit dimensions to images is straightforward. INP requires fundamental changes to JavaScript architecture.The Three Phases of INP That PageSpeed Doesn't Show YouINP measures the complete timeline from user input to visual feedback. It breaks down into three phases:Input Delay: The time between when a user interacts and when event handlers can start running. This happens when the main thread is blocked by other tasks.Processing Time: The time spent executing event handler code. Heavy JavaScript execution, complex DOM manipulation, or synchronous operations all contribute to this.Presentation Delay: The time between when event handlers finish and when the browser paints the next frame. Rendering work, layout recalculation, and compositor tasks add delay here.PageSpeed Insights shows you metrics related to these phases in lab data, but they don't map directly to INP:Total Blocking Time correlates with Input Delay but doesn't measure interactionsTime to Interactive relates to Processing Time but only measures initial page loadThere's no lab equivalent for Presentation Delay at allThe result: developers fix what PageSpeed highlights (render-blocking resources, JavaScript bundle size) and see their lab scores improve. But these fixes often don't address the specific interactions causing poor INP in the field.Real User Monitoring (RUM) tools can show you which specific interactions are slow, but PageSpeed Insights can't. You need to instrument your own analytics or use a dedicated RUM solution to actually diagnose INP failures.Why Most Performance Fixes Don't Improve INPWe see this pattern constantly. A client comes to us after their development team "fixed" their performance issues. They installed caching plugins, compressed images, enabled lazy loading, added a CDN. Their PageSpeed score went from 45 to 75.Their bounce rate didn't improve. Their conversion rate stayed flat. Their Search Console still shows failing Core Web Vitals.Surface fixes address symptoms. INP failures are structural.The real killers:Third-party scripts loading synchronously. Analytics trackers, chat widgets, ad networks, personalization tools. Each one executing long tasks on the main thread while users are trying to interact.Event handlers doing too much work. A button click that triggers form validation, updates multiple UI elements, fires tracking events, and makes an API call all in one execution block. Users wait while the browser grinds through it.Large DOM trees. When you have 3,000+ DOM nodes, even simple interactions require expensive layout recalculation. The browser has to figure out what changed and repaint accordingly.Unoptimized JavaScript frameworks. React components that re-render the entire tree instead of surgical updates. Vue watchers that trigger cascading updates. Next.js apps that don't code-split properly and ship massive bundles.No interaction feedback. Users click a button and nothing happens for 400ms. They click again, thinking it didn't work. Now the browser has two interactions queued up, and chaos ensues.These problems don't show up in PageSpeed's lab tests because the lab doesn't interact with your site the way real users do. It loads the page, measures some metrics, and reports back. It doesn't open accordions, submit forms, filter product lists, or toggle mobile menus.How We Actually Fix INP (With Real Numbers)Red Curtain Addict came to us with a PageSpeed score of 35/100. Their mobile site took over 6 seconds to load. Bounce rates were climbing. Search rankings were slipping.Their existing development team had tried the usual fixes. Image compression, caching plugins, CDN setup. The score barely moved.We ran a comprehensive performance audit and found the real problems:Bloated third-party scripts loading synchronously before contentUnoptimized server response times adding 2+ seconds before first byteRender-blocking JavaScript preventing interactivityOversized hero images loading above the fold without optimizationPoor Core Web Vitals across all three metricsThe INP issues specifically:Form submissions taking 800ms+ to provide visual feedbackMobile menu toggle requiring 500ms to respondFilter interactions on product pages experiencing 600ms delaysAll caused by long-running JavaScript tasks blocking the main threadWe implemented fixes at the codebase level:Script loading strategy: Async/defer for non-critical third parties, inlined critical scripts, removed unnecessary analytics trackers that were executing on every interaction.Event handler optimization: Broke up long tasks into smaller chunks using setTimeout to yield to the main thread. Added immediate visual feedback (loading states, disabled buttons) before heavy processing.DOM optimization: Reduced component complexity, implemented virtual scrolling for long lists, lazy-loaded below-the-fold interactive elements.Server-side optimization: Improved TTFB from 2.1s to 0.4s, added caching layers, optimized database queries that were slowing API responses.Results:PageSpeed score: 35 → 95 (171% improvement)Loading speed (LCP): 6.2s → 1.8sVisitor retention: 40% increaseTimeline: 3 weeksMore importantly, their field data showed passing INP scores for the first time. Form submissions responded in under 150ms. Menu interactions felt instant. Product filters updated smoothly.The difference between what we did and what most teams try: we fixed the code, not just the configuration.What Google's December 2025 Update ChangedGoogle's December 2025 Core Update increased the weight of technical performance factors. Sites with poor INP scores (over 300ms) experienced 31% more traffic loss than sites with good responsiveness, particularly on mobile devices.The threshold hasn't changed. Good INP is still under 200ms at the 75th percentile. But the ranking impact has intensified.Sites with LCP over 3.0 seconds saw 23% more traffic loss than faster competitors with similar content quality. The message is clear: technical excellence is no longer optional for competitive rankings.In competitive niches where multiple sites offer similar content quality and authority, the site delivering superior user experience gains the decisive advantage. Pages ranking at position 1 are 10% more likely to pass Core Web Vitals thresholds compared to URLs at position 9.The business impact extends beyond rankings. Sites passing all three Core Web Vitals thresholds see 24% lower bounce rates, measurably better organic rankings, and higher user engagement.Real case studies back this up:The Economic Times reduced INP from 1 second to 257ms, leading to a 50% decrease in bounce rate and 43% increase in pageviews.T-Mobile saw a 20% reduction in on-site issues and a 60% increase in visit-to-order rate after focusing on Core Web Vitals.Trendyol reduced INP by 50%, resulting in a 1% uplift in click-through rate. Ray-Ban doubled conversion rate and reduced exit rate by 13% through pre-rendering.How to Actually Diagnose Your INP IssuesPageSpeed Insights won't tell you what's causing your INP failures. Here's what will:Step 1: Check if you have field dataGo to PageSpeed Insights and test your site. Look at the top section labeled "Discover what your real users are experiencing."If it says "The Chrome User Experience Report does not have sufficient real-world speed data for this page," you don't have enough traffic for CrUX data yet. You'll need to implement your own Real User Monitoring.If you see field data, look at your INP score. Green (under 200ms) means you're passing. Yellow (200-500ms) means you need improvement. Red (over 500ms) means you're failing.Step 2: Use Search Console to find failing pagesNavigate to Core Web Vitals report in Google Search Console.Filter by INP to see which URL groups are affected. This helps identify patterns. Is it just your homepage? Product pages? Blog posts? Checkout flow?Step 3: Identify the specific interactionsPageSpeed Insights can't tell you which interactions are slow. You need one of these:Chrome DevTools Performance panel: Record a session while you interact with your site. Look for long tasks (over 50ms) on the main thread. These block responsiveness.Real User Monitoring tools: DebugBear, SpeedCurve, or similar services collect INP data from real users and show you which specific interactions are problematic.web-vitals JavaScript library: Google maintains this library that measures INP client-side. You can log the data to your analytics platform.Step 4: Profile the slow interactionsUse Chrome DevTools to profile the specific interaction. Click the slow button or menu. Look at what JavaScript is executing. Common culprits:Third-party scripts: Tag managers, analytics, chat widgets, consent bannersHeavy framework operations: Large React re-renders, Vue computed property cascadesSynchronous API calls: Network requests blocking the UI threadDOM manipulation: Updating thousands of elements at onceLayout thrashing: Reading and writing layout properties in the same taskStep 5: Implement the fixesBreak up long tasks. Use requestIdleCallback or setTimeout to yield to the main thread. Defer non-critical work until after the interaction completes.Add immediate visual feedback. Show loading states, disable buttons, display spinners before heavy processing starts. Users tolerate delays better when they know something is happening.Code-split your JavaScript. Don't ship a 500KB bundle when users only need 50KB for the current interaction.Optimize event handlers. Remove unnecessary work. Batch DOM updates. Use event delegation instead of individual listeners on every element.Move work off the main thread. Use Web Workers for heavy computations. Let the browser handle rendering while workers crunch data in the background.The Field Data vs Lab Data Gap (And Why It Matters)Here's a common scenario: You run PageSpeed Insights. Lab data shows 100/100. Performance score is perfect. Total Blocking Time is 0ms.You check Search Console. Core Web Vitals report shows "Poor" for INP. Your site is failing in the field.How is this possible?Lab tests use controlled conditions. Lighthouse simulates a mid-tier mobile device on a 4G connection. Real users have everything from high-end phones on fiber to budget devices on spotty 3G.Lab tests don't interact. They load the page and measure. They don't click your menus, submit your forms, filter your products, or open your accordions. INP measures interactions the lab never performs.Lab tests use empty cache. Real users often have warm caches, which can make some things faster. But they also have browser extensions, other tabs running, and background processes that slow JavaScript execution.CrUX data is a 28-day rolling average. If you just deployed a fix, it won't show up in field data for weeks. Lab tests show improvement immediately.The solution: Use lab data for debugging, field data for validation.When you see a failing INP score in Search Console, use PageSpeed's lab tools to investigate. Run performance profiles in Chrome DevTools. Identify the slow interactions. Fix them. Then wait 28 days to see if field data improves.Don't chase perfect lab scores. Chase passing field data thresholds.What To Do NextIf you're reading this and realizing your site might be failing INP without you knowing it:Run PageSpeed Insights on your key pages.Check if you have field data.Look at your INP scores.Check Google Search Console.Navigate to Core Web Vitals, See which pages are failing.Profile your most important interactions.Use Chrome DevTools to record what happens when users click your primary CTAs, submit forms, or navigate your site.If you find issues and don't know how to fix them, you have two options:Fix it yourself. Use the techniques above. Break up long tasks. Optimize event handlers. Add visual feedback. Test until field data improves.Hire someone who's done this before. We took Red Curtain Addict from 35 to 95 in three weeks because we've fixed these problems at scale. Six Flags processed over $1B in transactions through a mobile app we optimized for 30 million users. Every millisecond mattered there. It matters for your business too.Get a free performance analysis if you want to know exactly what's slowing you down and what it's costing you in conversions.Either way, don't ignore this. Google's December 2025 update made the ranking impact clear. Sites with poor INP are losing traffic to faster competitors.The gap between lab scores and field performance is real, and it's measurable in your business metrics.43% of sites are failing INP. Most of them don't know it yet. Now you do.