LCP vs INP: The Core Difference
LCP (Largest Contentful Paint) measures how long it takes for the largest visible element on a page — typically a hero image, product photo, or headline — to fully render in the viewport. It captures a single moment: the end of the perceived load experience. A good LCP score is under 2.5 seconds.
INP (Interaction to Next Paint) measures responsiveness throughout the entire page session. It records the delay between a user input — a click, tap, or keypress — and the moment the browser visually updates in response. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. A good INP score is under 200 milliseconds.
The clearest way to separate them: LCP is a loading metric, INP is an interactivity metric. LCP fires once per page load; INP accumulates data across every interaction a user performs during their visit, then reports the worst-case response time.
How Each Metric Is Measured
LCP is calculated from the moment navigation starts (or the page becomes visible) to the point the browser paints the largest image or text block above the fold. The browser continuously updates its candidate as elements load, settling on a final value when the user first scrolls or interacts. Tools like Google PageSpeed Insights, Chrome User Experience Report (CrUX), and Lighthouse all surface LCP directly.
INP works differently. The browser logs the input delay, processing time, and presentation delay for every discrete interaction on the page. At the end of the session, it reports the highest latency interaction — with a small allowance for statistical outliers on very interaction-heavy pages. This means a single sluggish button click can drag down an otherwise responsive page.
Because INP is session-wide and LCP is load-specific, they are captured by different measurement windows. Lab tools like Lighthouse can approximate LCP reliably but struggle with INP because lab environments don't replicate real user interaction patterns. Field data from CrUX is the authoritative source for INP.
Where They Overlap and Where They Diverge
Both metrics contribute to Google's Core Web Vitals assessment, which feeds into page experience signals used in Search ranking. A page that fails either metric is flagged as a poor experience in Google Search Console. That shared ranking consequence is the main overlap.
The divergence is in what causes poor scores. LCP problems trace back to resource loading: unoptimized images, render-blocking scripts, slow server response times (TTFB), and missing preload hints. INP problems trace back to JavaScript execution: long tasks on the main thread, third-party scripts competing for CPU, and unoptimized event handlers that block the browser from repainting.
A page can have excellent LCP and terrible INP — common on ecommerce sites that deliver a fast initial render but then load heavy product-filtering scripts, chat widgets, or personalization layers that jam up the main thread. The reverse is also possible: a page that loads slowly but responds instantly once loaded.
Ecommerce Scenarios Where Each Metric Matters Most
LCP is the dominant concern on landing pages, product detail pages, and category pages where the first visual impression drives conversion. A hero image that loads in 4 seconds costs bounce rate and ad Quality Score. Optimizing LCP means compressing images, using a CDN, eliminating render-blocking resources, and preloading the LCP element.
INP becomes critical on pages where users interact repeatedly before converting: filtering a product grid, adding items to a cart, applying coupon codes, or navigating a multi-step checkout. A 600ms delay after clicking 'Add to Cart' is invisible in LCP data but is felt immediately by the customer and is captured in INP.
Search-result pages and faceted navigation are high-INP-risk zones. Every filter click triggers JavaScript that re-renders the product list. If that JavaScript runs on the main thread in a single long task, INP spikes. Breaking that work into smaller tasks or moving it off the main thread with web workers directly reduces INP without changing LCP at all.
Diagnosing and Fixing Each Metric
To diagnose LCP, open Chrome DevTools Performance panel or PageSpeed Insights and identify the LCP element. Common fixes: convert hero images to WebP or AVIF, add a preload link for the LCP image, reduce server response time, and remove render-blocking stylesheets or scripts above the fold.
To diagnose INP, use the Chrome DevTools Performance panel with interaction tracing enabled, or install the Web Vitals Chrome extension and interact with the page while watching the INP readout. The goal is to find long tasks triggered by user inputs. Common fixes: defer non-critical JavaScript, split long tasks with scheduler.yield() or setTimeout(0), and audit third-party scripts that execute on click events.
Do not treat LCP improvements as a proxy for INP improvements. Deferring JavaScript to improve LCP can actually worsen INP if it causes a burst of script execution right when users start interacting. Sequence fixes carefully and test both metrics together after each change.
Actionable Priority Framework
Audit LCP first on your highest-traffic acquisition pages — homepage, top category pages, and paid landing pages. These are the pages where a poor LCP directly affects bounce rate and paid ad efficiency. Use field data from CrUX (visible in Search Console under Core Web Vitals) to see which URLs are actually failing for real users.
Audit INP on pages with the highest interaction depth: product listing pages with filters, cart pages, and checkout flows. Set up Real User Monitoring (RUM) that captures INP by page template, not just by URL, since product listing pages share a template but have different data loads.
Run both audits on mobile separately from desktop. Mobile devices have slower CPUs and more constrained memory, which means INP scores are consistently worse on mobile than desktop for the same page. Prioritize mobile fixes — they affect the majority of ecommerce traffic and carry the same weight in Google's Core Web Vitals assessment.