INP and LCP Measure Completely Different Things
LCP (Largest Contentful Paint) measures load performance — specifically, how long it takes for the largest visible element on the page (a hero image, a headline block, a product photo) to fully render after navigation begins. It answers the question: how fast does the page appear ready to the user?
INP (Interaction to Next Paint) measures responsiveness — specifically, the worst-case delay between a user's input (click, tap, keystroke) and the next frame the browser paints in response. It answers a different question entirely: how fast does the page react once the user tries to do something? These are distinct phases of the user experience, and a page can score well on one while failing the other.
Mechanics: How Each Metric Is Calculated
LCP timestamps a single event: the moment the browser marks the largest above-the-fold element as fully painted. Google's threshold for a 'Good' LCP score is under 2.5 seconds. The measurement window opens at navigation start and closes when the element renders. LCP is a load-phase metric — it captures the first impression, not ongoing interaction.
INP samples every qualifying interaction throughout the entire page visit, not just the first one. It records the input delay, processing time, and presentation delay for each interaction, sums them into a single latency value, and takes the highest percentile response across the session (excluding statistical outliers). Google's threshold for a 'Good' INP score is under 200 milliseconds. Because INP evaluates the full session, a slow interaction triggered by a lazy-loaded component or a cart drawer minutes after page load still counts against the score.
The calculation difference matters for diagnosis. LCP problems surface in waterfall charts and resource timing — you look at network requests, render-blocking assets, and server response times. INP problems surface in long task traces and main thread utilization — you look at JavaScript execution, event handler cost, and layout thrashing triggered by interactions.
When Each Metric Applies to Ecommerce Pages
LCP is the dominant concern on landing pages, category pages, and product detail pages where the primary goal is presenting content fast. A slow-loading hero image, a server-side rendered page with a long time-to-first-byte, or a render-blocking font all damage LCP. For paid traffic campaigns where first impressions drive bounce rate, LCP is the more commercially urgent metric.
INP becomes the dominant concern on pages with rich interactivity: add-to-cart flows, filter and sort panels, size selectors, quantity steppers, coupon code fields, and checkout forms. A product page with a fast LCP but a sluggish add-to-cart button has a good first impression and a bad conversion experience. For checkout pages specifically, INP directly maps to the friction a buyer feels while completing a purchase.
Many ecommerce pages have both problems simultaneously. A JavaScript-heavy storefront might use a large product image that loads slowly (LCP) while also running heavy third-party scripts that block the main thread and slow button responses (INP). Treating them as the same problem leads to misdiagnosed fixes.
Where INP and LCP Overlap — and Where They Diverge
The most common overlap is main thread congestion. A page loading large JavaScript bundles to render its LCP element is also occupying the main thread during the critical load window. That same JavaScript execution creates long tasks that raise INP by blocking event handlers from responding quickly. Reducing JavaScript parse and execution time improves both metrics simultaneously — it is one of the few interventions that moves the needle on both.
Beyond that overlap, the metrics diverge sharply. Image optimization — compressing the hero image, using modern formats like WebP or AVIF, adding explicit width and height attributes — directly improves LCP and has no meaningful effect on INP. Conversely, deferring or replacing a heavy click-handler library, breaking up a long synchronous event handler, or moving cart logic off the main thread with a Web Worker improves INP and has no effect on LCP.
Server-side rendering (SSR) and static site generation improve LCP by delivering fully rendered HTML before JavaScript executes. They do not automatically improve INP — hydration-heavy SSR frameworks can actually introduce INP regressions if the hydration process creates long tasks during or after page load.
How Google's Core Web Vitals Program Treats Both
Both INP and LCP are official Core Web Vitals and contribute to Google's page experience signal used in organic ranking. LCP has been a Core Web Vital since the program launched. INP replaced FID (First Input Delay) as the responsiveness Core Web Vital in March 2024. A page must pass all three Core Web Vitals thresholds (INP, LCP, and CLS) to qualify for a 'Good' page experience designation in Search Console.
Google measures both metrics using real-user data from the Chrome User Experience Report (CrUX), not synthetic lab tests. This means PageSpeed Insights and Search Console surface field data for both. Lab tools like Lighthouse measure LCP accurately but cannot fully simulate INP — Lighthouse uses Total Blocking Time (TBT) as an INP proxy in lab environments.
Prioritizing Fixes: Which Metric to Address First
Start with whichever metric is failing according to Search Console's Core Web Vitals report for your actual URLs. If both are failing, prioritize LCP first for high-traffic acquisition pages — slow load times create abandonment before users ever interact. Fix INP first for high-intent conversion pages like cart and checkout, where users are already engaged and interaction friction directly costs revenue.
Audit each metric with the right tool. Use WebPageTest or Lighthouse for LCP — identify the LCP element, trace its request chain, and eliminate render-blocking resources. Use Chrome DevTools Performance panel with interaction tracing enabled for INP — record a session, trigger your key interactions, and inspect the long tasks that follow each input event. Combining both diagnostics into one audit session gives a complete picture of where load performance ends and interaction performance begins.