How to Pass Google's New Website Speed Test

Imagine clicking a contact form's "Submit" button and nothing happens for almost half a second. You click again. Still nothing. Then both submissions fire at once.

That invisible freeze is exactly what INP captures, and it silently kills conversions on sites that look perfectly fine on the surface.

This post is part of my Technical SEO guide series.

What INP Actually Tracks

INP stands for Interaction to Next Paint. Google replaced FID (First Input Delay) with INP because FID had a glaring blind spot: it only measured the delay on a visitor's very first interaction. A page could score perfectly on FID while being painfully sluggish on every subsequent click, tap, or keystroke.

INP watches everything. Every button press, every form field entry, every accordion toggle. It records the time between the user's action and the moment the browser visually responds. Then it reports the 98th percentile, essentially the worst interaction your visitors experience.

If someone taps your navigation menu and the browser takes 420ms to paint the dropdown, that's your INP score for that visit (assuming nothing worse happened). Google calls that "poor."

The scoring brackets

• Good: 200ms or less
• Needs improvement: 200ms to 500ms
• Poor: Over 500ms

Why Rankings Depend on INP

INP sits alongside LCP and CLS as one of three Core Web Vitals that directly factor into Google's ranking algorithm. Failing any of the three tells Google your user experience has problems.

But forget rankings for a second. Think about what poor INP feels like from a visitor's perspective. They tap a button. Nothing happens. They wait. They wonder if it registered. They tap again. Maybe the page jumps or double-fires an action. That moment of uncertainty is where you lose people.

Poor INP leads to:

• Visitors abandoning forms mid-completion
• Higher bounce rates on interactive pages
• Fewer completed purchases on e-commerce sites
• A general sense that your business feels "broken" online

The Usual Suspects Behind Poor INP

JavaScript hogging the main thread

Browsers run JavaScript and handle user interactions on the same thread. When a heavy script is executing, clicks and taps sit in a queue waiting their turn. The bigger your JavaScript bundles, the longer visitors wait.

Common offenders include bloated analytics setups, live chat widgets that load eagerly, complex animation libraries, and state management frameworks that re-evaluate the entire application on every interaction.

Oversized DOM trees

A page with 3,000 or 4,000 DOM elements forces the browser to do more work every time something changes visually. Each interaction that triggers a layout recalculation becomes slower because the browser has to evaluate thousands of nodes. WordPress sites using page builder plugins often generate over 6,000 DOM elements because the builder wraps every element in three or four nested containers.

Framework rendering overhead

Single-page application frameworks can create INP nightmares when they re-render large component trees in response to small state changes. A toggle switch that updates a single boolean shouldn't cause 200 components to re-evaluate, but without careful optimization, that's exactly what happens in some React and Vue applications.

My Approach to Fixing INP

Start with server-side rendering

SSR is consistently the single biggest INP improvement available. When the server delivers fully rendered HTML, the browser can display content and respond to interactions without waiting for a massive JavaScript bundle to parse and execute. The initial JavaScript payload shrinks because the framework doesn't need to build the page from scratch on the client.

Strip unnecessary JavaScript

I audit every script on the page and ask three questions: Is this doing something the user needs right now? Can it load later? Can it be replaced with something lighter?

Practical steps to take:

• Split code so each page only loads what it needs
• Tree-shake unused exports from bundles
• Defer scripts that aren't needed until the user scrolls or interacts
• Replace heavy libraries with lighter alternatives when the full feature set isn't needed

Speed up event handlers

When a click handler runs, it should finish fast. Moving expensive computation into web workers, using requestAnimationFrame for visual updates, and applying debouncing to high-frequency events like scroll and resize all help. Synchronous layout reads followed by writes inside event handlers cause forced reflows, which is one of the sneakier causes of slow interactions.

Simplify the DOM

Fewer elements means faster paint updates. Virtualizing long lists so only visible items exist in the DOM, removing unnecessary wrapper elements that page builders love to generate, and favoring CSS-based visual effects over JavaScript-driven DOM manipulation all contribute to faster interactions.

Audit every third-party script

Third-party scripts are frustrating because you can't control their code quality. A chat widget vendor might push an update that adds 100ms to every interaction on your site, and you'd never know unless you're watching INP metrics.

For each third-party script, evaluate whether it's essential, whether it can load after the page is interactive, and whether a lighter alternative exists. Swapping a heavy analytics suite for a lightweight option like Plausible can shave 100ms or more off INP scores based on web performance case studies.

Measuring INP in Practice

Field data from real visitors

Lab tests are useful for debugging, but field data tells you what actual visitors experience on actual devices:

• Google Search Console reports Core Web Vitals field data collected from Chrome users
• Chrome User Experience Report (CrUX) provides aggregated performance data at the origin and URL level
• The Web Vitals JavaScript library lets you capture INP events in your own analytics, broken down by page, interaction type, and device

Lab tools for debugging

When field data reveals a problem, switch to lab tools to find the root cause:

• Chrome DevTools Performance panel: Record yourself interacting with the page, then inspect the flame chart for long tasks that overlap with your interactions
• Lighthouse: Offers an INP assessment with specific recommendations
• WebPageTest: Provides detailed interaction timing across multiple test runs

My debugging workflow

1. Pull CrUX data to identify which pages have poor field INP scores
2. Open those pages in Chrome DevTools and record a performance trace while clicking through the interface
3. Look for long tasks (anything over 50ms) that coincide with user interactions
4. Trace those tasks back to specific scripts, handlers, or rendering cycles
5. Implement fixes and verify with lab testing
6. Monitor CrUX data for four to six weeks to confirm real-world improvement

Common INP Problems and How to Fix Them

FAQ accordions with forced layout recalculation

A common issue on small business sites is FAQ sections where tapping any question freezes the page for 300ms or more. The usual culprit is JavaScript using getBoundingClientRect() on every FAQ item to calculate animation heights, triggering a forced layout recalculation across the entire page. Replacing the JavaScript height animation with a CSS max-height transition can drop INP for that interaction to under 50ms.

Chat widgets blocking the main thread

Many small business sites load a 200 to 300KB chat widget script synchronously on every page. That script blocks the main thread for nearly a full second during page load, which means the first few interactions after landing on any page are sluggish. Setting the widget to load only after the page is fully interactive, triggered by an intersection observer when visitors scroll near the contact section, can improve INP from over 500ms to around 100ms.

Gallery and portfolio re-renders

Sites using React or Vue galleries often re-render every thumbnail (sometimes 30 to 50 of them) whenever a visitor clicks to view a full-size image. Each click triggers layout calculations for elements that haven't changed. Applying React.memo to thumbnail components and adding viewport-based virtualization so only visible thumbnails exist in the DOM can reduce INP from 400ms or more to under 100ms.

Platform-Specific INP Challenges

WordPress

Plugin bloat is the usual problem. Every plugin adds JavaScript: sliders, form builders, analytics, social sharing, cookie banners. WordPress sites running 15 or more plugins can often cut INP in half by reducing to eight essential ones and deferring the rest. Heavy page builders like Elementor generate massive DOM trees and load substantial JavaScript; switching to a lighter theme framework often produces dramatic INP improvements.

Shopify and e-commerce

Product filtering, cart interactions, and payment embeds all create INP pressure. The most impactful fix is usually the product filter. Server-round-trip filtering forces visitors to wait for a network request on every filter change. Client-side filtering with pre-loaded product data feels instant for catalogs under 500 items.

React and Next.js applications

Virtual DOM reconciliation is the core INP risk. Every state update can potentially re-render a large component tree. React DevTools Profiler pinpoints which components re-render on each interaction, making it easier to apply memoization where it matters. Next.js server components are especially valuable for INP because they never ship JavaScript to the client.

INP and Conversion Rates

A site that responds to clicks in under 100ms feels instant. At 300ms, the delay is noticeable. Past 500ms, visitors start wondering if the page is broken.

Industry data consistently shows that moving from "poor" to "good" INP correlates with conversion rate improvements of 10 to 20 percent. Google's own case studies have documented similar patterns. Smooth interactions keep visitors engaged through multi-step processes like checkout flows and contact forms.

Mobile performance matters most here. Mobile processors are weaker than desktop ones, so INP problems are always worse on phones. Since mobile-first indexing means Google evaluates your mobile experience first, and since most local searches happen on phones, your mobile INP score is the one that counts. Test on a mid-range Android phone, not your development laptop.

Where INP Fits in the Bigger Picture

INP is one piece of the Core Web Vitals trio, alongside LCP (loading speed) and CLS (visual stability). Passing all three tells Google your site delivers a solid user experience. I cover the full technical picture in my technical SEO guide, and the security foundations that support performance in my post about HTTPS and trust signals.

Frequently Asked Questions

What is the difference between INP and FID?

FID only measured the first interaction, while INP tracks every interaction throughout the entire visit and reports the worst one. FID only measured the delay of the first interaction on a page. A visitor could click a button as the page loaded, get a good FID score, and then experience terrible responsiveness on every subsequent click.

INP tracks every interaction throughout the entire visit and reports the 98th percentile, giving a much more honest picture of real user experience. Google made the switch because FID was too easy to pass while actual responsiveness remained poor.

Does poor INP on one page hurt my entire site's rankings?

Google evaluates INP at the page level, but widespread failures across your site signal a systemic problem that can hurt overall visibility. If most of your pages fail INP, it signals a systemic problem. The best approach is to prioritize fixing the highest-traffic pages first, typically the homepage, main service pages, and top-performing blog posts.

Those pages affect the most visitors and the most ranking signals.

How do I fix INP problems caused by third party scripts?

Remove non-essential scripts, defer the rest until after the page is interactive, and isolate heavy ones in web workers or iframes. You can't edit someone else's code, so the approach is layered. First, remove any third-party scripts that aren't essential. Second, defer the remaining ones until after the page is fully interactive using async or defer attributes.

Third, consider isolating heavy scripts in web workers or iframes to keep them off the main thread. For analytics specifically, lightweight alternatives like Plausible or Fathom use a fraction of the JavaScript that Google Analytics requires.

How do I check my website's INP score?

Enter your URL into Google's PageSpeed Insights and check the INP metric under Core Web Vitals for both lab and field data. For hands-on debugging, open Chrome DevTools, go to the Performance panel, and record yourself interacting with the page. Look for long tasks (over 50ms) that align with your clicks or taps.

Chrome also has a Web Vitals overlay that displays real-time INP measurements, available in the Rendering tab of DevTools.

Every millisecond of unresponsive interaction costs you visitors who silently leave and never tell you why. While you wait, competitors with snappier sites are converting the same audience.

Picture every button, form, and menu on your site responding instantly. Visitors stay engaged, complete your forms, and walk away feeling like your business runs as smoothly online as it does in person.

Want to find out if your site passes INP? Let's check.