Core Web Vitals: LCP, INP and CLS Explained

Core Web Vitals are the bridge metrics between technical SEO and actual user experience. They translate abstract performance concepts into three measurable values that Google collects directly from the browsers of real visitors. This article explains LCP, INP, and CLS in detail, puts their realistic weight as a ranking signal into perspective, and shows how to improve the metrics in a modern stack of Next.js, edge/CDN, and HTTP/3. The focus is on mobile use, which in Austria, for example, accounts for most internet access.

Why Core Web Vitals matter for technical SEO

Core Web Vitals are the part of page experience that Google promotes and uses in its ranking systems. In its official documentation, Google makes clear that there is no single page experience signal, but that its ranking systems use Core Web Vitals and that a good page experience can contribute to success in Search for queries with a lot of helpful content (Google Search Central). So the three metrics are not a primary ranking factor. They are a reliable quality signal that tips the balance mainly when several results of equal content quality compete.

Real-world data shows how much room for improvement there is. According to the Web Almanac 2024, only 43 percent of mobile origins pass all three Core Web Vitals; on desktop, the figure is 54 percent (HTTP Archive, Web Almanac 2024). If you get this right, you stand out from more than half of the mobile web. This is particularly relevant for Austria, because internet use there is strongly mobile: in June 2024, 81.5 percent of internet access in Austria came from mobile devices. A large share of that went through apps. The mobile web accounted for 31.6 percent of all access (Statista, Österreichische Webanalyse). For Core Web Vitals, only the browser share counts, and a large part of it is mobile as well.

The three metrics and their thresholds

Google segments the assessment into good, needs improvement, and poor, and always measures at the 75th percentile of page views, separately for mobile and desktop. The official good thresholds are: LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less (web.dev). In concrete terms, the 75th percentile means that three out of four page views must meet the threshold; the worst quarter does not count. A page therefore only passes a Core Web Vital when it is reliably fast, not just under ideal conditions.

• Largest Contentful Paint (LCP): measures when the largest visible element in the viewport has rendered. It is the proxy for perceived loading speed.
• Interaction to Next Paint (INP): measures the latency between a user interaction and the next visible frame update, across the entire session.
• Cumulative Layout Shift (CLS): measures the largest burst of unexpected layout shifts during the entire lifespan of the page, in other words how stable the content remains (web.dev).

At the level of individual metrics, the picture in the mobile segment is mixed. In 2024, 59 percent of mobile pages achieved a good LCP, 74 percent a good INP, and 79 percent a good CLS (Web Almanac 2024). This makes LCP the most frequently missed of the three metrics on mobile devices.

LCP in detail: optimizing perceived loading

LCP is almost always about an image. On 73.3 percent of mobile pages, the LCP element is an image (Web Almanac 2024). This makes the LCP image the single most important optimization lever. The typical causes of slow LCP fall into three areas: a high server response time (TTFB), render-blocking resources such as CSS and JavaScript in the critical path, and the pure load time of the LCP resource itself.

The most effective countermeasures target exactly these points:

• Control priority: Mark the LCP image with fetchpriority="high" and, if needed, request it early via <link rel="preload"> so the browser does not queue it behind less important resources.
• Never lazy-load the LCP image: A widespread anti-pattern. 16 percent of mobile pages lazy-load their LCP image, 9.5 percent even via the native loading="lazy" (Web Almanac 2024). The LCP element belongs above the fold and must be loaded eagerly.
• Use modern image formats: AVIF and WebP reduce file size significantly compared with JPEG and thus shorten the resource load time.
• Lower TTFB via edge/CDN: Delivery from a CDN node close to the user and modern transport protocols shorten the server response time before a single pixel is rendered.

INP in detail: ensuring interactivity

INP replaced FID as a Core Web Vital on March 12, 2024, and at the same time took the place of FID in Search Console (web.dev). The switch was not cosmetic: FID only measured the delay of the first interaction, while INP evaluates all interactions in a session and is significantly stricter. This shows in the numbers: with FID, 48 percent of mobile pages would still have had good CWV in 2024; with INP, it is only 43 percent (Web Almanac 2024).

INP consists of three phases: input delay (the wait until the event handler can start), processing time (execution of the handler), and presentation delay (the time until the next frame). By far the most common cause of poor INP is blocking JavaScript that occupies the main thread and backs up interactions. This leads to three levers, which the article optimizing INP covers in detail:

• Split long tasks (task splitting): Break large JavaScript tasks into smaller chunks and hand control back to the browser in between, for example with scheduler.yield() or deferral, so input does not have to wait.
• Decouple events (debouncing): Throttle frequently firing handlers such as scroll or input events so expensive logic does not run on every pixel.
• Offload work (web workers): Move compute-intensive work that is not related to the UI into a web worker to keep the main thread free.

CLS in detail: maintaining visual stability

CLS assesses the visual stability of a page: it penalizes content that still jumps after the first render. The causes are well known: images and iframes without fixed dimensions, dynamically loaded content inserted above existing content, late-loading web fonts that cause a layout jump, and ad slots without reserved space. The countermeasures are consistently preventive:

• Specify dimensions: Always set width and height or an aspect-ratio for images and videos so the browser reserves the space before loading.
• Reserve space for dynamic elements: Provide fixed slots in the layout for ads, embeds, and late-loading banners instead of pushing them into the flow.
• Soften font swaps: Use font-display and preloaded fonts to minimize text reflow when the font swaps.

With 79 percent good scores on mobile devices, CLS is the best-controlled of the three metrics (Web Almanac 2024). The reason is that the countermeasures are technically simple and only need to be implemented once.

Best practices: CWV in the Next.js and edge stack

In Next.js, many CWV optimizations are already built into the framework's building blocks, but you have to use them deliberately. next/image enforces dimensions and serves modern formats. For the most important image, fetchPriority="high" raises the load priority, which directly improves LCP. Up to Next.js 14, the priority attribute set this value automatically. Since Next.js 15, priority only handles preloading and eager loading, and you have to set fetchPriority="high" yourself (Next.js, Pull Request #67351). Since Next.js 16, priority is deprecated in favor of preload, and the Next.js documentation recommends fetchPriority="high" or loading="eager" in most cases. next/font loads fonts locally and self-hosted, which avoids the font-related layout jump that worsens CLS. Streaming via SSR and React Server Components reduces the JavaScript sent to the client, which defuses the main cause of poor INP.

The most critical point in the App Router is hydration. Every interactive client component has to be hydrated in the browser, and too much client JavaScript creates exactly the long tasks that drive INP up. In practice, this means: keep as much as possible as Server Components, limit interactivity to small client islands, and load heavy components on demand.

The technical foundation amplifies these effects. On the web, 54 percent of more than 1.3 billion requests are now delivered via a CDN, while HTTP/3 is available on around 30 percent of pages but is actually used on only 7 to 9 percent of first page loads (Web Almanac 2024, HTTP). Edge caching and HTTP/3 lower TTFB and with it the starting point of LCP, without any change to the front-end code.

Faster, cleanly cached delivery also benefits crawl budget and AI crawlers, which fetch the web on a growing scale: Googlebot traffic grew by 96 percent from May 2024 to May 2025, and Googlebot holds around 50 percent of the crawler share, while GPTBot rose from 2.2 to 7.7 percent (Cloudflare). A fast page with predictable delivery is therefore also an advantage for Generative Engine Optimization (GEO).

Common mistakes in CWV optimization

• Mistaking lab values for reality: A green Lighthouse score in the lab says nothing about what Google evaluates. What counts is the 75th percentile of real users.
• Lazy-loading the LCP image: The most common self-inflicted damage to LCP. The element above the fold must never be loaded with a delay.
• Confusing INP with FID: If you still optimize for FID, you are measuring the wrong metric. Since March 2024, INP has been the only relevant interactivity metric.
• Checking CLS only at the top of the page: Layout shifts often only happen while scrolling or with late insertions. CLS is measured over the entire lifecycle of the page.
• Testing only on desktop: Google assesses mobile and desktop separately, and significantly fewer origins pass all three metrics on mobile (43 versus 54 percent, Web Almanac 2024). Tests must run on mobile with a throttled CPU and network.

Measurement: lab vs. field and the right tools

The most important distinction is the one between lab and field data. Lab data is generated in a controlled environment, for example in Lighthouse, and is suited to debugging and reproducible comparisons. It does not feed into ranking, though. Field data comes from real users and is evaluated at the 75th percentile (web.dev). Only this real-user data counts for the assessment.

• Chrome UX Report (CrUX): The official field data source, aggregated from real Chrome users. It is the basis for the Search Console report and PageSpeed Insights.
• PageSpeed Insights: Combines CrUX field data at the top with a Lighthouse lab run below. Ideal for seeing the real-world status and the technical cause side by side.
• Search Console Core Web Vitals report: Groups URLs into good, needs improvement, and poor based on field data and shows the trend over time for the entire property.
• RUM and web-vitals.js: Your own real-user monitoring in code, for example via the web-vitals.js library, delivers continuous field data and granular diagnostics, also for tools like DebugBear.

If you consistently separate lab and field, you avoid the most common misinterpretation: reading a good lab result as a passed Core Web Vital.

CWV as a ranking signal and the business case

The realistic expectation is this: Core Web Vitals replace neither relevance nor high-quality content. Google states explicitly that there is no single signal and that it always wants to show the most relevant answer, even when the page experience is subpar, but that a good page experience can make the difference for queries with a lot of helpful content (Google Search Central). CWV therefore act as an amplifier and tie-breaker, not as a shortcut past weak content.

The stronger lever is often conversion. The redBus case study documented by Google shows that targeted INP optimization increased sales by 7 percent, with INP itself improving by 72 percent, among other things through debounced scroll handlers and fewer API requests (web.dev, redBus). These figures come from an international case, but the mechanism carries over: faster interactions reduce drop-offs and increase completed purchases. In the Austrian context, where most internet access is mobile (Statista), every mobile INP or LCP improvement directly reaches a large share of visitors. The business case for CWV is therefore less an SEO argument than a revenue argument with an SEO side effect.

Further reading

Core Web Vitals are most effective when they are embedded in your entire technical SEO stack. LCP depends on TTFB and therefore on edge/CDN caching and HTTP/3, INP on your JavaScript and rendering strategy, and all three benefit from a clean Next.js architecture with minimal client JavaScript. If you invest here, you improve delivery to classic crawlers and AI crawlers alike, and with it your GEO visibility. You can go deeper in the articles on JavaScript SEO and rendering, HTTP/3 and performance infrastructure, edge SEO at the CDN level, CDN and server location, and Next.js SEO architecture.