Guides
Core Web Vitals and SEO: LCP, INP & CLS Explained
Core Web Vitals measure loading speed, responsiveness, and visual stability. This guide shows how to read the data, isolate the failing metric, fix its actual cause, and validate the result.
Run a fresh DomainLens audit and use the report as your priority list.
What are Core Web Vitals?
Core Web Vitals are Google’s three user-centred performance metrics. Together they answer practical questions a visitor notices immediately: did the main content appear quickly, did the page respond when I used it, and did the layout stay put while I was trying to read or tap?
Google uses Core Web Vitals within its broader page-experience systems. They are also useful engineering targets in their own right: each metric points to a different class of performance problem, so a single generic instruction to “make the site faster” is not enough.
LCP — Largest Contentful Paint
LCP measures how long it takes to render the largest content element visible in the viewport. That element is often a hero image, banner, poster frame, or large heading. To the visitor, LCP is the moment the page finally looks useful rather than merely started. The LCP diagnosis below breaks the timing into server, discovery, download, and render delay.
INP — Interaction to Next Paint
INP observes click, tap, and keyboard interactions across a visit and reports a representative high-latency interaction. It includes input delay, the event handler’s work, and the time needed to present the next frame. A poor INP feels like a menu, filter, or button ignored the user before suddenly catching up.
INP replaced First Input Delay as a Core Web Vital in 2024 because FID measured only the delay before the first interaction handler began. It did not capture slow handler execution or presentation delay, and it ignored later interactions. INP describes responsiveness across the visit much more completely.
CLS — Cumulative Layout Shift
CLS measures unexpected movement of visible content. A late image that pushes a paragraph down, an ad that opens above a button, or a cookie banner injected into normal document flow can all create layout shifts. The damage is not abstract: a user can lose their reading position or tap the wrong control. The CLS diagnosis below covers shift attribution and stable layout patterns.
Core Web Vitals thresholds
Google evaluates each metric at the 75th percentile, separately for mobile and desktop. If the mobile LCP at p75 is 2.4 seconds, at least 75% of measured mobile visits were at or below 2.4 seconds. The slowest quarter still matters: improving only fast devices or office Wi-Fi may leave the p75 unchanged.
A page passes Core Web Vitals only when all three metrics are good at the 75th percentile. One green Lighthouse run does not establish that. It is one synthetic load with a particular device, network profile, location, and page state; it cannot represent 28 days of real visits, and Lighthouse cannot directly measure INP without real user interactions.
These thresholds and the p75 assessment come from the official web.dev Web Vitals guidance .
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5s | > 2.5s and ≤ 4.0s | > 4.0s |
| INP | ≤ 200ms | > 200ms and ≤ 500ms | > 500ms |
| CLS | ≤ 0.1 | > 0.1 and ≤ 0.25 | > 0.25 |
Do Core Web Vitals affect SEO rankings?
Yes, Google says its ranking systems use Core Web Vitals. The careful answer is that they are one part of page experience, not a dominant score that overrides relevance. A highly useful page can rank with poor Core Web Vitals, while a fast but unhelpful page has no entitlement to rank. Chasing a perfect performance score solely for SEO is usually a worse investment than fixing a clearly poor real-user experience.
Core Web Vitals do not determine whether robots.txt permits crawling, whether a robots meta tag permits indexing, or which canonical Google selects. Performance can affect how users experience a page and can contribute to ranking, but it should not be used to explain every crawling or indexing problem.
Google’s own page-experience documentation explicitly says there is no single page-experience signal and that good Core Web Vitals do not guarantee top rankings.
| Concept | Question it answers | What CWV changes |
|---|---|---|
| Crawling | Can Googlebot fetch the URL? | Nothing about robots.txt permission or HTTP access |
| Indexing | Can and does Google store the page? | CWV is not an indexability directive |
| Canonicalization | Which duplicate URL represents the content? | CWV does not replace canonical signals |
| Ranking | Where can an indexed result appear? | CWV contributes as part of broader page experience |
| Page experience | Is the result pleasant and usable? | CWV directly measures three important aspects |
Field data vs lab data
Field data: what visitors experienced
Field data comes from real page visits. Google’s Chrome User Experience Report (CrUX) aggregates eligible Chrome users and reports a rolling 28-day view at URL or origin level when enough data exists. It captures the device mix, networks, cache states, interactions, geography, and long sessions that a lab test cannot reproduce.
Field data is the evidence used to judge whether users pass Core Web Vitals, but it is deliberately aggregated. It can tell you that mobile LCP is poor; it usually cannot identify the exact request or CSS rule responsible.
Lab data: a repeatable debugging environment
Lighthouse loads a page under controlled conditions and records a trace. That makes it useful before release and after each change: you can find the LCP element, render-blocking resources, unused JavaScript, long tasks, and layout-shift sources under the same test profile.
A lab run measures that run, not your audience. Lighthouse reports LCP and CLS, but it cannot measure INP because no real person completes a sequence of interactions. Total Blocking Time is a useful laboratory clue for main-thread congestion, not a substitute value for INP.
CrUX vs Lighthouse vs PageSpeed Insights vs Search Console
Start in Search Console when the question is “which parts of the site fail?” Open PageSpeed Insights or DomainLens for a representative URL when the question becomes “which metric fails here?” Use Lighthouse and Chrome DevTools when you need the trace, request priority, long task, or shifting element that explains the result. Query CrUX directly when you need field trends or programmatic URL/origin data.
Always note whether a tool shows URL-level or origin-level field data. A low-traffic page may have no URL record and fall back to the whole origin. That is useful context, but it is not proof that this exact template behaves the same way.
| Tool | Data | Best used for |
|---|---|---|
| Lighthouse | Lab | Reproducing and debugging a page load |
| CrUX | Field | Real-user performance at URL or origin level |
| PageSpeed Insights | Field + lab | Investigating a URL in one view |
| Search Console | Field | Monitoring groups of similar URLs across a site |
How to improve LCP
First identify the LCP element and split its time into server delay, resource discovery, resource download, and render delay. Optimizing an image file will do little when the browser discovered it two seconds late; adding a CDN will not solve a hero hidden behind client-side rendering.
If the server responds slowly
Inspect the document request in the Network panel and compare Time to First Byte across cached and uncached requests. Check application queries, full-page caching, CDN cache status, redirects, and distance to origin. A slow HTML response delays discovery of every later resource.
If the LCP element is a hero image
Confirm the image URL appears in the initial HTML, starts early in the waterfall, and is not marked for lazy loading. Check its intrinsic pixels against the rendered size and serve an appropriate srcset in WebP or AVIF where supported. Above-the-fold LCP images generally should not wait for lazy-loading before being requested.
<img
src="/images/hero-1280.webp"
srcset="/images/hero-640.webp 640w, /images/hero-1280.webp 1280w"
sizes="(max-width: 640px) 100vw, 1280px"
width="1280"
height="720"
fetchpriority="high"
alt="SEO report showing Core Web Vitals">If rendering starts late
Look for render-blocking CSS, font requests, and client-side code that must finish before the LCP element exists. Inline only genuinely critical CSS, defer non-critical styles, subset and preload only the font needed above the fold, and server-render meaningful content when a JavaScript app otherwise creates it late. The JavaScript rendering guide explains how to verify the server response and rendered DOM separately.
If results vary between visits
Compare CDN cache headers and cache-hit status, test from the regions that supply traffic, and check whether personalization or consent changes the hero. An LCP regression that appears only on a cold cache or one mobile template can disappear in a convenient desktop retest.
How to improve INP
Debug the interaction users actually report: opening navigation, changing a product filter, adding to cart, or typing in search. Record a Performance trace, perform that action several times, and inspect the slow interaction. Separate input delay, handler duration, and presentation delay before choosing a fix.
Audit third-party scripts separately. A tag manager, chat widget, A/B testing library, or ad script can occupy the main thread at the exact moment a user interacts. Delay non-essential tags, load them after consent or intent, and remove vendors whose cost exceeds their value.
- 1Find the slow interaction in field data or reproduce a likely high-value action on a representative mobile device.
- 2In Chrome DevTools, inspect the interaction and the main-thread tasks around it. A task over 50ms is a strong place to investigate.
- 3Expand the call stack. Look for large framework updates, repeated DOM queries, JSON parsing, synchronous storage, expensive validation, or third-party callbacks.
- 4Remove unnecessary work, split the remaining work, and yield between chunks so the browser can paint. Debounce work that does not need to run on every keystroke.
- 5Reduce rendering cost: update the smallest DOM region, avoid layout thrashing, and keep oversized DOM trees out of frequently updated components.
- 6Retest the same interaction and monitor real-user INP after deployment. A lower TBT is encouraging, but field INP is the validation metric.
button.addEventListener("click", async () => {
updateVisibleState();
await scheduler.yield();
calculateSecondaryResults();
});How to improve CLS
Use the Performance panel or layout-shift diagnostics to identify the element that moved and the element that caused it to move; they are not always the same. Then reserve space before asynchronous content arrives.
- Images and video: set width and height, or an aspect-ratio, so the browser allocates the box before the file downloads.
- Ads and embeds: give the slot a stable minimum size. Do not collapse it when an ad is unavailable if that pulls the page upward after load.
- Injected banners and cookie notices: overlay them or reserve their final space from the initial render instead of inserting them above existing content.
- Web fonts: use a suitable fallback with compatible metrics, preload only critical fonts, and avoid swapping to a face whose dimensions substantially change line breaks.
- Dynamic content: update inside an existing container or add content below the current viewport when possible.
Bad: the browser does not know the image ratio
<img src="product.jpg" alt="Blue running shoe">Good: dimensions reserve the final space
<img
src="product.jpg"
width="800"
height="600"
alt="Blue running shoe">Real diagnostic example: isolate the failing metric
Suppose PageSpeed Insights shows field data for an important landing page: LCP 3.4s, INP 160ms, and CLS 0.04. INP and CLS are already good. The page does not need a broad “Core Web Vitals optimization”; it needs an LCP investigation.
- 1Identify the failing metric. LCP at 3.4s is in “Needs improvement”; INP and CLS are not the current bottleneck.
- 2Open the Lighthouse trace and find the LCP element: <img class="hero-image">.
- 3Inspect its Network request. The 2400px JPEG is 620KB, starts after the JavaScript bundle, and the HTML marks it loading="lazy".
- 4Remove lazy loading from this above-the-fold image, expose it in the server-rendered HTML, add fetchpriority="high", and provide a correctly sized responsive WebP/AVIF source.
- 5Repeat the same mobile lab profile. Confirm that the image starts immediately and that LCP falls without creating a CLS regression.
- 6Deploy, then watch URL-level field data. Because CrUX is a rolling 28-day dataset, the field value improves gradually as new visits replace old ones.
How DomainLens helps with the workflow
Run an audit for the exact URL, then open the Core Web Vitals and page-performance checks. DomainLens requests mobile and desktop data, prefers URL-level CrUX data when it is available, labels an origin-level fallback, and shows the metric value, category, and distribution. That distinction matters: an origin fallback is context, not a measurement of the exact page.
Next, use the Lighthouse diagnostics in the same report. For LCP, inspect the LCP element, document latency, render-blocking resources, image delivery, and font findings. For responsiveness, inspect Total Blocking Time, main-thread work, long tasks, DOM size, and third-party code. For CLS, inspect the reported layout-shift elements and whether media or dynamic slots reserve space.
DomainLens helps you move from “which metric failed?” to a short list of likely causes while keeping status code, robots, canonical, and other technical checks visible. For deciding whether a lab improvement reflects field performance, compare Core Web Vitals with Lighthouse scores .
DomainLens cannot replace Search Console’s site-wide URL grouping, the 28-day observation window, or your own real-user monitoring. It also cannot infer the business importance of a page or decide whether a third-party feature is worth its performance cost. Use it for evidence and diagnosis, then validate the deployed result with field data.
What should I fix first?
Prioritize by affected template, field severity, traffic, conversion value, and confidence in the diagnosis. Fixing one product-page component used by 20,000 URLs is usually more valuable than polishing a low-traffic page from 96 to 100 in Lighthouse.
| Priority | Fix when | Reason |
|---|---|---|
| Critical | Poor field CWV affects a shared template; LCP exceeds 4s on key landing pages; major mobile CLS causes mis-taps | Many users and valuable URLs receive a clearly poor experience |
| High | An important template is in “Needs improvement” or a regression is spreading through new deployments | The fix can improve a meaningful cohort before it becomes poor |
| Medium | Field data is good but repeatable lab traces expose a likely regression or a critical interaction is slow | Preventive work is justified when evidence is consistent |
| Lower | One lab run is slow while field CWV is good and repeated tests cannot reproduce it | Investigate during normal performance work; do not displace proven user problems |
Core Web Vitals FAQ
- Are Core Web Vitals a Google ranking factor?
- Yes. Google says its ranking systems use Core Web Vitals as part of page experience. They do not outweigh relevance and content quality, and a good result does not guarantee high rankings.
- Does the Lighthouse score affect Google rankings?
- No direct ranking signal is the Lighthouse performance score. Lighthouse is a lab diagnostic. Google’s Core Web Vitals assessment is based on real-user data, not your 0–100 lab score.
- Why does PageSpeed Insights differ from Search Console?
- They may show a specific URL versus a group of similar URLs, URL versus origin data, and different update views. Search Console and CrUX also reflect a rolling 28-day field window, while the Lighthouse section is a fresh lab run.
- How long does Search Console Core Web Vitals take to update?
- The underlying field assessment uses a rolling 28-day window, so changes are not immediate. New good visits progressively replace older data; Search Console reporting can add processing delay.
- Can a page rank with poor Core Web Vitals?
- Yes. Google aims to return the most relevant helpful result even when its page experience is weaker. Poor CWV can still be a disadvantage when competing pages are similarly useful.
- Should I optimize for Lighthouse 100/100?
- Not as an SEO goal. Fix user-visible bottlenecks and prevent regressions. Once field CWV is good, extra work for a perfect lab score should compete normally with content, accessibility, and product priorities.