Core Web Vitals Explained: LCP, INP and CLS Made Simple
- Level: Intermediate
- #Technical SEO
- #Metrics
- #Google Search Console

Core Web Vitals are three Google metrics that measure the real experience of a page: LCP (loading speed, ideally within 2.5 seconds), INP (response to clicks, ideally within 200 milliseconds) and CLS (visual stability, ideally within 0.1). They are part of page experience and help SEO, but they do not replace relevant content.
Quick summary
- LCP measures when the largest visible element on the page finishes appearing. Good: up to 2.5 s. Poor: above 4 s.
- INP measures the time between a click, tap or keypress and the page's visual response. Good: up to 200 ms. Poor: above 500 ms. It replaced FID in March 2024.
- CLS measures how much the layout "jumps" while loading. Good: up to 0.1. Poor: above 0.25.
- The target is the 75th percentile of real visits, with mobile and desktop reported separately.
- To measure, use the Search Console report and PageSpeed Insights. Real-world data comes from CrUX, and the lab test is for debugging.
- Google says relevance comes first: a page that is great on speed but weak on content does not win.
How to read this: if you run a site but do not code, read the definitions, the thresholds table and the list of steps, which tell you what to ask your developer. If you already do technical SEO, go to the sections on field versus lab data, ranking weight and fixes by metric. This post complements technical SEO for non-programmers and uses terms defined in the SEO, AEO and GEO glossary.
What are Core Web Vitals?
They are three metrics Google chose to represent the experience of using a page: loading (LCP), interactivity (INP) and visual stability (CLS). The Google Search documentation recommends achieving good values on them for success in Search, and says they align with what Google's core ranking systems seek to reward.
In plain English: imagine walking into a physical store. LCP is how long it takes for the main counter to appear. INP is how long the clerk takes to react when you raise your hand. CLS is the floor moving under you: you go to press a button and suddenly it shifts, and you click the wrong one.
For SEO professionals: Core Web Vitals are the subset of metrics Google treats as essential and collects in CrUX. There are other useful diagnostic metrics (TTFB, FCP, TBT), but only LCP, INP and CLS count toward the "passed or failed" assessment in the Search Console report.
What are the official LCP, INP and CLS thresholds?
The official thresholds, according to the web.dev documentation, are in the table below. They are evaluated at the 75th percentile of visits, meaning 75% of visits must fall within the "good" threshold for the page to pass, and the data is segmented between mobile and desktop.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | When the largest visible element finishes rendering | up to 2.5 s | 2.5 s to 4 s | above 4 s |
| INP (Interaction to Next Paint) | Latency of interactions until the next visual frame | up to 200 ms | 200 ms to 500 ms | above 500 ms |
| CLS (Cumulative Layout Shift) | Sum of the largest burst of unexpected layout shifts | up to 0.1 | 0.1 to 0.25 | above 0.25 |
Two notes prevent confusion. First, CLS has no unit: it is a score, calculated from the impact of the shift on the screen multiplied by the distance the elements moved. Second, INP replaced FID (First Input Delay) as an official metric on March 12, 2024, according to the web.dev announcement. If an old report still cites FID, it is out of date.
What is LCP and how do you improve it?
LCP records when the largest visible element (usually a hero image, a video or a large block of text) finishes loading. The web.dev definition counts images, videos, CSS background images and blocks of text, and the final value is the last largest element recorded before the user's first interaction.
The web.dev guide to optimizing LCP splits the time into four parts: time to first byte (about 40%), resource load delay (under 10%), resource load duration (about 40%) and element render delay (under 10%). The suggested order of attack is to eliminate the load delay and render delay first, then reduce the download and, lastly, the server response time.
Fixes that tend to bring the most return:
- Never apply
loading="lazy"to the main above-the-fold image. Lazy loading is for what sits below. - Mark the main image with
fetchpriority="high"and keep it visible in the initial HTML, not injected by JavaScript later. - Compress the image and serve it at the right size, in a modern format such as WebP or AVIF, and use a CDN.
- Cut redirects and speed up the server, because LCP includes connection and response time. Prefer rendering the main content on the server.
For SEO professionals: look at the hero image in the lab report and check whether it is the LCP element. A frequent mistake is the carousel or slider that loads the first slide via script. Another: fixing image weight when the real bottleneck is TTFB, which the four-part breakdown shows immediately.
What is INP and how do you improve it?
INP measures page responsiveness by observing the latency of all clicks, taps and keypresses during the visit, from the moment of the action until the browser shows the next frame with a visual response. Scrolling, hovering and zooming do not count, per web.dev's explanation of INP. Unlike the old FID, which only looked at the first interaction, INP covers the entire page.
Each interaction has three phases: input delay (the browser is still busy), processing time (your code reacts) and presentation delay (the browser draws the result). The web.dev guide to optimizing INP recommends breaking up long JavaScript tasks, doing as little as possible inside event handlers, deferring non-essential work, reducing DOM size and avoiding alternating layout reads and writes.
In practical terms:
- Remove or defer third-party scripts that freeze the page: chat widgets, pixels, A/B tests.
- Split heavy functions into smaller chunks, yielding control back to the browser between them.
- Show some immediate feedback on click (a loading state) before processing everything.
In plain English: INP is the "click" feel of the button. If you click "Add to cart" and nothing happens for half a second, INP is poor, even if the page loaded fast.
What is CLS and how do you improve it?
CLS measures how much visible elements shift unexpectedly while you use the page. web.dev groups the shifts into "session windows" (bursts with at most 1 second between them and 5 seconds in total duration) and reports the largest window. Shifts caused by a user click, within 500 ms, are considered expected and do not count.
The most common causes and fixes, according to the web.dev guide to optimizing CLS:
- Images and videos without dimensions: always declare
widthandheight, or useaspect-ratioin CSS. - Ads, embeds and banners that appear later: reserve the space with
min-heightoraspect-ratiobefore the content arrives. - Fonts that swap after loading: use
font-display: optionalor similar fallback fonts to reduce the text jump. - Animations: prefer
transformover changingtop,leftor sizes, becausetransformdoes not force the rest of the page to move.
How do you measure Core Web Vitals on your site?
Measure with three tools: the Core Web Vitals report in Search Console to see the whole site, PageSpeed Insights to analyze a single URL and the browser itself for debugging. The difference that changes everything is field data (real users) versus lab data (a simulated test).
The Search Console report uses CrUX, the Chrome User Experience Report, which gathers anonymous metrics from real visits. It groups similar URLs, classifies each group as good, needs improvement or poor, and the group's status is that of its worst metric. When you fix an issue and click to validate, Google tracks CrUX for 28 days to confirm.
PageSpeed Insights shows both kinds of data. Field data is the history of the last 28 days in CrUX. Lab data comes from a Lighthouse simulation, under a single device and network condition. If the site does not have enough traffic, PSI does not show field data for the URL and may fall back to origin level, or show nothing.
For SEO professionals: when field and lab diverge, trust the field to decide whether there is a problem and use the lab to find the cause. Lab tests that only load the page do not measure INP; reproduce real flows (opening the menu, filtering, adding to cart) in DevTools. To measure on your own site, the web-vitals JavaScript library, maintained by the Chrome team, collects the metrics while handling cases the raw browser API misses.
Step by step for a 30-minute diagnosis
- Open the Core Web Vitals report in Search Console, for mobile and desktop, and see which URL groups are "poor" or "need improvement".
- Take one representative URL from each group (a product, a category, an article) and run it through PageSpeed Insights.
- Compare the field data with the lab data. Note which of the three metrics fails.
- For LCP, identify the element and the four parts of the time. For CLS, see which elements move. For INP, test the most-used interactions in DevTools.
- Fix one cause at a time, publish, and wait about 28 days of field data before concluding. Validate in Search Console.
Do Core Web Vitals affect ranking?
They do, but modestly and without replacing relevance. Google's guidance on page experience says Search always seeks to show the most relevant content, even if the page experience is not great, and that there is no single signal: the systems look at several signals tied to the overall experience.
In practice: do not sacrifice content to gain 0.2 seconds, and do not ignore a page that fails all three metrics. A slow, laggy page loses visitors before any algorithm gets involved, which is a practical reason (conversion and retention) independent of ranking. On priority, the sensible order is indexing and content first, Core Web Vitals next and fine-grained performance last. The step-by-step SEO audit shows where this check fits in, and the on-page SEO checklist covers the page's own items.
Hypothetical example: a store has a category page with a 3.8 s LCP. The LCP element is a promotional banner that loads via JavaScript after everything else. The team applies fetchpriority="high" to the banner, removes loading="lazy" and serves it in the initial HTML. Lab LCP drops to near the good threshold. The result in field data only shows up after about four weeks, and the effect on ranking, if any, will be modest. The guaranteed gain is the experience of the people who visit.
Frequently asked questions
Are Core Web Vitals a Google ranking factor?
Yes, they are part of the page experience signals, but Google makes clear that content relevance comes first and that there is no single decisive signal. Good values help, but they do not compensate for weak content. Treat them as part of a healthy foundation, together with indexing, content and links.
What changed from FID to INP?
FID only measured the delay of the first interaction. INP observes all clicks, taps and keypresses during the visit and includes the time until the browser shows the result. It became a stable Core Web Vital on March 12, 2024, and FID was retired. That is why INP is more demanding and reveals problems FID hid.
Why does PageSpeed Insights show different scores from Search Console?
Because they measure different things. Search Console uses field data aggregated by URL group, with a 28-day history. PageSpeed Insights shows the specific URL, with field data when it exists and a simulated lab test. Divergence is normal. Use the field to decide and the lab to debug.
My site has little traffic and no field data shows up. Now what?
Without enough volume, CrUX does not publish data for the URL, and PageSpeed Insights uses the origin or shows nothing. In that case, use the lab tests as a guide, follow the best practices for each metric and, if you want real data, install the web-vitals library on the site to collect your own measurements.
Next step
If your site still has basic indexing problems, solve them before optimizing milliseconds: review how Google crawls, indexes and ranks and set up Google Search Console to follow the experience reports. If you publish articles on WordPress and want to keep up your content pace, see how Contentor generates articles with AI and review the result against the best practices in this guide.
Read also:
Prepare your content for AI answers
Create AEO/GEO briefs, entities, schema, and structured articles for Google AI Overviews, AI Mode, and traditional SEO.
Try Contentor freeStrengthen your authority for AI Search
Combine source-worthy content with contextual backlinks on vetted sites to reinforce trust, discovery, and topical authority.
View contextual backlinks


