INP vs CLS: The Core Distinction
INP (Interaction to Next Paint) measures how long the browser takes to visually respond after a user interaction — a click, tap, or keypress. It captures the worst-case interaction delay across an entire page session and reports it in milliseconds. A score under 200ms is considered good; above 500ms fails.
CLS (Cumulative Layout Shift) measures unexpected visual movement of page elements during load or after user actions. It produces a unitless score by multiplying the fraction of the viewport affected by a shift against the distance those elements moved. A score under 0.1 is considered good; above 0.25 fails.
The clearest dividing line: INP is about time — how fast the page reacts to you. CLS is about space — whether the page stays visually stable. A page can have perfect INP and terrible CLS, or vice versa. They measure entirely separate dimensions of user experience.
How Each Metric Is Measured and Scored
INP is collected from real user interactions via the Event Timing API. During a session, every qualifying interaction is timed from the moment the event fires to the moment the next frame is painted. At session end, the highest-latency interaction (with minor outlier trimming on long sessions) becomes the INP score. This makes INP sensitive to rare but severe slowdowns — a sluggish checkout button click counts heavily.
CLS is calculated continuously throughout a page's lifespan. Each layout shift gets a score, and shifts within a 1-second window are grouped into session windows. The largest session window's cumulative score becomes the final CLS score. This means a single large shift — like an ad loading and pushing the Add-to-Cart button down — can dominate the entire score.
Both metrics live inside Google's Core Web Vitals framework and feed into the Chrome User Experience Report (CrUX), which informs Google Search ranking signals. Neither metric is captured solely from lab tools; both require real-user data to produce field scores, though lab approximations exist.
When INP Applies vs When CLS Applies
INP applies the moment a user does something: opens a filter drawer, selects a product variant, types in a search box, or taps a quantity selector. If the UI freezes for 600ms before responding, that registers as a poor INP event. INP is therefore most relevant on interaction-heavy pages — product listing pages with faceted filters, cart pages, and multi-step checkout flows.
CLS applies during page load and any subsequent dynamic content injection. It fires when images without declared dimensions render, when cookie consent banners appear above content, or when a late-loading font swap shifts a headline. On ecommerce sites, CLS frequently spikes on product pages where image carousels, promotional banners, or review widgets inject themselves after the initial paint.
The practical rule: if a user has not touched anything yet and elements are jumping around, that is a CLS problem. If a user taps a button and nothing visibly happens for a noticeable pause, that is an INP problem.
Where INP and CLS Overlap — and Conflict
There is one intersection worth understanding: user-initiated layout shifts. When a user clicks a button and the resulting DOM update causes elements to move unexpectedly, that shift is excluded from the CLS calculation because it was triggered by user input. However, the delay before that update paints is captured by INP. This means a poorly coded accordion or modal can fail INP without affecting CLS at all.
A conflict arises in optimization priorities. Reducing INP often means breaking long JavaScript tasks into smaller chunks using techniques like scheduler.yield() or moving work off the main thread. Reducing CLS means reserving space for dynamic content with explicit dimensions or CSS aspect-ratio boxes. These are entirely separate engineering efforts with no shared solution.
One indirect relationship exists: heavy JavaScript that causes long tasks (hurting INP) can also delay resource loading, which sometimes worsens CLS by pushing late-loading elements into the viewport after initial paint. Fixing main-thread congestion can improve both metrics simultaneously, but this is a side effect rather than a shared root cause.
Ecommerce Scenarios That Expose Each Metric
INP failures are common on product listing pages with client-side filtering. When a shopper clicks a facet checkbox and the product grid re-renders via JavaScript, that re-render blocks the main thread. If the process takes 700ms, INP registers a poor interaction. Cart pages with real-time price calculation and checkout pages with address validation are other frequent INP failure points.
CLS failures are common on homepage hero sections where a promotional banner loads after the initial paint, pushing navigation links down. Product detail pages with lazy-loaded images that lack explicit width and height attributes are another standard source. Review carousels that inject content below the fold after DOMContentLoaded also accumulate CLS score.
A quick diagnostic split: use Chrome DevTools' Performance panel to identify long tasks on click events for INP issues, and use the Layout Instability API or the CLS breakdown in PageSpeed Insights to pinpoint which elements are shifting and when for CLS issues.
Which Metric to Fix First
Prioritize INP when users interact frequently with the page and report the interface feeling unresponsive. On ecommerce sites, this translates to faceted search, cart interactions, and checkout forms. A failing INP score (above 500ms) on any of these pages directly delays purchase completion and increases abandonment at the most revenue-critical moments.
Prioritize CLS when users report clicking the wrong element or when analytics show rage-clicks or mis-taps concentrated near dynamic content areas. A high CLS score on a product page where the Add-to-Cart button shifts can cause accidental taps on adjacent elements — a direct revenue problem.
If both scores fail, start with CLS. Layout shifts are typically fixed through static HTML and CSS changes — declaring image dimensions, reserving ad slots — which carry lower engineering risk than rearchitecting JavaScript execution for INP. CLS fixes also tend to improve perceived load quality faster, making subsequent INP improvements more noticeable to users.