---
title: Core Web Vitals for SEO: LCP, INP, CLS
category: guide
canonical: https://forgehouse.ai/guides/core-web-vitals-seo/
lang: en
hreflang_alt: https://forgehouse.ai/tr/rehberler/core-web-vitals-seo/
last_updated: 2026-06-20
---

# Core Web Vitals for SEO: LCP, INP, CLS

> Core Web Vitals are Google's three page-experience metrics, LCP for loading, INP for interactivity and CLS for visual stability, measured from real Chrome users at the 75th percentile. They are a confirmed ranking signal and a direct driver of bounce, so this guide explains each metric, its passing threshold, and how to diagnose and fix it.

## What are Core Web Vitals (LCP, INP, CLS)?

Core Web Vitals are the three metrics Google uses to score how a page actually feels to a real person, measured from real Chrome visits rather than a synthetic test. They cover loading, interactivity and visual stability, and they sit inside Google's wider page-experience signals. The point is not a perfect score on a tool; it is whether a human on a mid-range phone gets a page that loads, responds and holds still.

The first metric, Largest Contentful Paint (LCP), measures loading. It marks the moment the biggest element in the viewport finishes rendering, usually the hero image, a video poster or a large block of heading text. LCP answers the only loading question a visitor cares about: how long until the main thing is on screen. It deliberately ignores the spinner and the favicon and watches the element that signals "this page has arrived."

The second metric, Interaction to Next Paint (INP), measures responsiveness. It became a Core Web Vital in March 2024, replacing First Input Delay, and it is a stricter test. Where the old metric only looked at the delay before the first interaction, INP observes every tap, click and key press during the whole visit and reports the slowest meaningful one. If a button feels dead for half a second after you press it, INP is the number that catches it.

The third metric, Cumulative Layout Shift (CLS), measures visual stability. It scores how much the layout jumps around without the user causing it, the late-loading banner that shoves the article down, the button that moves just as your thumb arrives. CLS is the metric behind the universal frustration of tapping the wrong thing because the page rearranged itself a beat too late. Together the three answer a simple question for both people and machines: did this page show up, work and behave.

## What are the passing thresholds?

A page passes Core Web Vitals when all three metrics land in the "Good" band at the 75th percentile of visits, which means roughly three out of four real loads have to meet the bar, not the average. Google publishes these thresholds openly, and they are the same numbers every credible tool reports.

| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP (loading) | 2.5 s or less | 2.5 s to 4.0 s | over 4.0 s |
| INP (interactivity) | 200 ms or less | 200 ms to 500 ms | over 500 ms |
| CLS (visual stability) | 0.1 or less | 0.1 to 0.25 | over 0.25 |

Two details trip up most people. First, the 75th percentile is unforgiving by design: your fast loads on a desktop with fibre do not rescue the slow loads on a three-year-old phone over patchy mobile data, because the metric is built to reflect the experience real users get, not the best case. Second, mobile and desktop are scored separately, so a page can pass on desktop and fail on mobile, and mobile is where most failures and most traffic live. The practical rule is to treat mobile field data as the real test and everything else as supporting evidence.

A useful way to read the bands is as a traffic light. "Good" is the only state that earns the page-experience benefit. "Needs improvement" means you are leaking experience and have a clear target to chase. "Poor" means the page is actively working against you, and at the 75th percentile that almost always traces back to a specific, fixable cause rather than a vague "the site is slow."

## Why is lab data different from field (CrUX) data?

Lab data and field data answer different questions, and confusing them is the most common reason teams "fix" Core Web Vitals and see no ranking effect. Lab data comes from a single controlled run, usually Lighthouse or the lab section of PageSpeed Insights, on one simulated device and network. Field data comes from the Chrome User Experience Report (CrUX), an aggregate of real Chrome users over a rolling 28-day window, and it is the data Google actually uses to assess the page.

The two diverge because the lab is a clean room and the field is the real world. A lab test on a fast simulated connection can post a flattering LCP while your real audience, scattered across cheap phones and congested networks, sits in the "Needs improvement" band. The gap is not a bug; it is the difference between one ideal load and the spread of thousands of imperfect ones. When lab looks great and field looks bad, trust the field, because that is what your visitors and Google both see.

There is also a hard limit on what the lab can measure. INP depends on real interactions, and a lab run does not click anything, so Lighthouse cannot produce a true INP value. It reports Total Blocking Time (TBT) instead as a proxy for how busy the main thread is, which correlates with INP but is not the same number. This is why a page can show a perfect Lighthouse score and still fail INP in the field: the proxy missed the real-world interactions that were slow. The working split is simple. Use field data (CrUX) to decide whether a page passes and which pages to prioritise, and use lab data (Lighthouse) to reproduce and debug the cause, because the lab gives you a repeatable trace while the field gives you the verdict.

## How do you diagnose a failing Core Web Vital?

Diagnosis follows one order every time: read the field data to see which of the three metrics is failing, then open the lab trace to find the cause, then fix the cause rather than chasing the score. Each metric has a short, well-understood list of culprits, so once you know which one is red, you are usually one or two changes away from green.

A failing **LCP** almost always comes from one of three places: a slow server response before anything can render, render-blocking CSS or JavaScript that delays the first paint, or a heavy hero resource that loads late. The fixes match the cause: cache and serve from a CDN to cut server time, defer non-critical scripts and inline the critical CSS, and for the hero image compress it, serve a modern format, size it responsively and tell the browser to load it first. Server-rendered or statically generated HTML beats client-side rendering here, because the main content does not wait on a JavaScript bundle to appear.

A failing **INP** is a main-thread problem: long JavaScript tasks block the browser so it cannot respond to the tap that already happened. The remedies break the work up, splitting long tasks, deferring or removing scripts the page does not need, shrinking the bundle, moving heavy computation to a web worker, and yielding back to the main thread so input gets a turn. A failing **CLS** is nearly always reserved space that was not reserved: images and embeds without width and height, ad or banner slots that inject content above what the reader is looking at, and web fonts that swap and reflow the text. The fixes are to set explicit dimensions or an aspect ratio, reserve the slot before the content arrives, and load fonts with a stable swap strategy.

This is the kind of repetitive, rule-bound checking an AI agent does well, which is the forgehouse angle. The PageSpeed Insights API returns both the CrUX field data and a Lighthouse lab run for any URL in one call, so an agent can pull Core Web Vitals across every important page, sort them by which fail at the 75th percentile, attach the likely cause from the lab trace, and hand back a ranked fix-this-first list instead of a wall of green and red. It turns a slow manual page-by-page audit into a minutes-long pass that tells you exactly where to spend the next hour. If you would rather not run that audit and the fixes yourself every month, [Vorkaz can monitor your Core Web Vitals and optimise your worst-performing pages for you](/vorkaz/seo-aeo).

## Do Core Web Vitals affect AI search visibility?

Core Web Vitals are a real ranking signal, but an honest answer puts them in proportion: they are part of page experience, which acts as a tiebreaker rather than a primary lever. Relevance and content quality decide most of the contest; Core Web Vitals decide the close calls, where two pages answer the query equally well and the faster, more stable one wins the visit and keeps it. Treating them as a magic ranking switch leads to disappointment, while treating them as the foundation a good page stands on is exactly right.

For AI answer engines the logic is the same foundation, viewed from a slightly different angle. An AI engine has to fetch and render a page before it can read and cite it, so a page that loads slowly, blocks the main thread or rearranges itself mid-render is a page that is harder to parse cleanly and more expensive to crawl. Speed and stability do not earn a citation on their own, but they remove the friction that stops your content from being read in the first place, which is why technical health and content quality reinforce each other rather than compete. A fast, stable page also keeps the human who clicks through from an AI answer, and that retained visit is the signal that compounds.

The practical takeaway is to keep Core Web Vitals green as table stakes, not as a growth strategy. Get the page loading, responsive and stable so neither Google nor an AI engine has a reason to discount it, then put your real effort into the content and authority that actually win the ranking. You can [track Core Web Vitals over time alongside your clicks and impressions in Search Console](/guides/gsc-analysis-claude/), so a regression shows up as a trend you can act on rather than a surprise. This whole workflow sits inside [the full AI SEO automation system](/guides/automate-seo-claude/), and the read-the-field-then-fix discipline above is exactly what the [SEO Analytics MCP Kit](/ai-kits/seo-analytics-mcp-kit/) packages as a repeatable connector to the PageSpeed Insights API.

---
Maker: Can Davarcı, https://candavarci.com.tr