INP, LCP and CLS in 2026: the three metrics that decide whether your site sells or is abandoned

If your page is slow to display the product, doesn't respond to the first tap, or moves when the customer is about to click "Submit," the visit is lost. Google summarizes this experience in three field metrics called Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). These don't replace your sales analytics. They do, however, tell you, with publicly available and stable thresholds, whether the page feels usable for the majority of those who visit it.

INP replaced First Input Delay (FID) as the interactivity metric. A previous article on this blog stated that INP "should be greater than 200 ms." That's the opposite. According to web.dev/articles/vitals (updated October 31, 2024) and the definition of thresholds , a good INP is 200 milliseconds or less . This text adheres to those official figures. We don't invent conversion or traffic percentages.

The three metrics, with Google's thresholds

Core Web Vitals measure load, interactivity, and visual stability. Google evaluates them at the 75th percentile of actual visits, separately for mobile and desktop. A page "passes" only if all three are rated "good" at that percentile. The official cutoffs are:

• LCP (perceived load): good ≤ 2.5 s (2,500 ms); needs improvement between 2.5 s and 4 s; poor > 4 s.
• INP (response to click, touch or key): good ≤ 200 ms; needs improvement between 200 ms and 500 ms; poor > 500 ms.
• CLS (unexpected design shifts): good ≤ 0.1; poor > 0.25.

The same threshold applies to mobile and desktop. In practice, the mobile report is usually the most demanding: that's where most of the traffic for a Mexican SME is concentrated.

These metrics aren't a secret ranking. They're documented in web.dev and in the Core Web Vitals report in Search Console . They help you and your team speak the same language: "the catalog's LCP on mobile is poor" is an actionable phrase; "the site feels slow" isn't.

LCP: when the main content appears

LCP reports the moment the largest visible element in the window is rendered: a cover image, a block of text, or a video. It's not the browser's load or the first pixel (that's FCP). It's the signal that the page is now displaying what the visitor came to see.

For a small or medium-sized business, a bad LCP ( Local PageSpeed ​​Insights ) problem is usually a heavy homepage without dimensions, a server that's slow to deliver HTML, or resources that block rendering (CSS and JavaScript in the <head> ` section). web.dev recommends measuring in the field with CrUX, PageSpeed ​​Insights, Search Console, and the web-vitals JavaScript library. In a lab environment, Lighthouse and DevTools are useful for reproducing the problem, not for declaring that "it's fixed now."

• Identify the LCP element in PageSpeed ​​Insights (field and lab).
• Reserve the width and height of the cover image; serve a compressed file, not a camera PNG.
• Prioritize critical HTML and CSS; stop blocking the first render with chat scripts, maps, or pixels.
• Check the Time to First Byte: if the server responds late, no image crop will reach 2.5 seconds.

An LCP of 2.5 seconds or less at the 75th percentile, on both mobile and desktop, is the "good" benchmark. Above 4 seconds, Google labels it as poor.

INP: the touch that doesn't belong at all

INP observes clicks, taps, and keystrokes throughout the entire visit—not just the initial gesture, which is what FID measured—and reports the slowest interaction, ignoring some outliers. Latency is measured from when the user initiates the gesture until the browser can render the next frame. An INP of 200 ms or less is considered good responsiveness; between 200 and 500 ms needs improvement; above 500 ms is poor.

On a small business website, the INP (Information Point) breaks down in contact forms, mobile menus, catalog filters, and "get a quote" buttons that trigger excessive JavaScript on the main thread. The user taps, sees no change, taps again, and the menu opens and closes repeatedly. This isn't just a "front-end issue": it's the reason they abandon the form.

• Measure INP in the field. In Lighthouse there is no comparable laboratory INP: the tool uses Total Blocking Time (TBT) as an approximation.
• Reduce lengthy work on the main thread: split tasks, defer third-party scripts, and avoid heavy listeners on every key.
• Give immediate feedback (status "sending", menu that starts to open) even if the network is slow.
• Experience the real-world flow on a mid-range phone, not just your laptop.

If someone tells you that the INP "has to be greater than 200 ms," correct them: ≤ 200 ms is acceptable. FID is no longer part of the stable set.

CLS: when the page moves under the finger

CLS counts unexpected jumps between visible elements. An ad that pushes a button, an image without a declared height, a font that changes size, or a cookie banner that pushes the content: the user intended to tap one thing and taps another. The acceptable threshold is 0.1 or less ; above 0.25 is poor. The percentile remains at 75, on both mobile and desktop.

Not every movement counts. A scroll that occurs very close to a user click (the API flags hadRecentInput if there's interaction within 500 ms) isn't treated the same as an unannounced jump. What does hurt is content that arrives late and scrolls across the rest of the page.

• Declare width and height (or aspect-ratio ) in images and videos.
• Reserve space for banners, embeds, and the cookie notice before injecting them.
• Avoid inserting ads or bars above the already painted content.
• Anime with transform , not changing top / left or the height of neighboring boxes.

How to measure: field first, lab later

Google emphasizes that Core Web Vitals are, first and foremost, field metrics. The Chrome User Experience Report (CrUX) feeds PageSpeed ​​Insights and the Search Console report. The web-vitals library allows you to send LCP, INP, and CLS to your own analytics. DevTools and Lighthouse are used for diagnostics during development; Lighthouse does not report INP and uses TBT as a proxy.

• Field: CrUX, PageSpeed ​​Insights, Search Console (Core Web Vitals report), web-vitals library.
• Lab: Chrome DevTools and Lighthouse (LCP and CLS yes; INP no — use TBT as a hint).

Search Console groups similar URLs and assigns the group's status to the worst metric. If CLS is poor and LCP is good, the group is considered poor. A small origin may not have enough data: in that case, PageSpeed ​​Insights still provides a lab test and, if available, displays the CrUX field for that URL.

If you need a website that loads, responds, and doesn't crash—catalog, form, or store—Presticorp works on that streamlining in pages for SMEs , and the same criterion applies to a startup MVP or an e-commerce checkout : first the HTML and images, then the extras.

14-day checklist (no made-up numbers)

Fourteen days isn't enough time to completely rebuild the site. It is enough time, however, to determine its current status and address the most common issues. Use this plan as a work order, not as a guarantee of passing the report: Crunchyroll and Search Console operate within a specific timeframe (approximately 28 days in the Search Console report).

• Days 1–2. Open Search Console → Core Web Vitals (mobile and desktop) and run PageSpeed ​​Insights on your homepage, a listing or service, and the contact form. Note the 75th percentile LCP, INP, and CLS. Separate "poor" from "needs improvement."
• Days 3–5 (LCP). Identify the LCP element. Compress the cover page, fix dimensions, and remove scripts from the <head> that don't render content. If the TTFB is high, talk to your hosting or caching provider before tweaking the CSS.
• Days 6–8 (INP). Record the quote/filter/open menu flow on a real phone. Clip third-party JavaScript (chat, maps, pixels) and avoid lengthy first-tap processing. Remember: the target field is ≤ 200 ms, not "more than 200."
• Days 9–11 (CLS). Size images, reserve space for the cookie banner, and stop injecting blocks above visible content.
• Days 12–14. Remeasure in the lab (Lighthouse/DevTools) to confirm the change is visible. In the field, don't expect Search Console to turn green the next day: start the fix tracking when you believe the group is no longer in poor, and continue monitoring PageSpeed ​​Insights weekly.

Passing the Core Web Vitals isn't a sales certificate. It's the minimum requirement for the customer to view, interact with, and submit content without struggling with the page.

The writer's suggestion

The three metrics can be summarized in a single sentence that you can stick next to your monitor: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1 , 75th percentile, mobile and desktop. INP has already replaced FID. The 200 ms threshold is a ceiling, not a floor.

This week, do just one thing: open PageSpeed ​​Insights with the URL that matters most to you (homepage or business page) and note the three field numbers. If INP or LCP are poor, don't start with a redesign: start with the LCP image and the JavaScript that runs on the first touch of the form. The 14-day checklist is for that purpose. If you want someone else to refine that area—template, homepage, forms, store—the published entry point is Presticorp's SME landing page .

Sources

• web.dev. "Web Vitals". Updated October 31, 2024. https://web.dev/articles/vitals
• web.dev. «Interaction to Next Paint (INP)». https://web.dev/articles/inp
• web.dev. "Largest Contentful Paint (LCP)". https://web.dev/articles/lcp
• web.dev. "Cumulative Layout Shift (CLS)". https://web.dev/articles/cls
• web.dev. «How the Core Web Vitals metrics thresholds were defined». https://web.dev/articles/defining-core-web-vitals-thresholds
• PageSpeedInsights. https://pagespeed.web.dev/
• Search Console Help. "Core Web Vitals report". https://support.google.com/webmasters/answer/9205520

Editorial note: The thresholds (LCP ≤ 2.5 s / poor > 4 s; INP ≤ 200 ms / poor > 500 ms; CLS ≤ 0.1 / poor > 0.25) and the 75th percentile criterion are taken from the cited web.dev pages, accessed on August 31, 2026. Conversion and traffic percentages are not attributed to these sources. FID is no longer Core Web Vital stable; its successor is INP.