Core Web Vitals Explained: LCP, INP, CLS, and Search Console

Most site owners judge speed by how a page feels on their own laptop, on a fast office connection. Google grades a different experience: how a page performs for real visitors across a wide range of devices and networks. Core Web Vitals exist to measure that gap in a consistent way.

This guide covers what the three metrics measure, the thresholds Google uses, how the data is collected, what you will see in Google Search Console, and what Bing Webmaster Tools offers in comparison.

What Core Web Vitals Actually Are

Core Web Vitals are a subset of Google's broader page experience signals, focused on measurable, user centered performance. They give site owners a consistent, standardized way to judge whether a page delivers a good experience, rather than relying on impressions like "it feels fast."

There are three Core Web Vitals metrics, and each one maps to a different part of how a person experiences a page:

• Loading is measured by Largest Contentful Paint.
• Responsiveness is measured by Interaction to Next Paint.
• Visual stability is measured by Cumulative Layout Shift.

All three are evaluated using real user data, not simulated lab tests, which is a distinction that trips up a lot of people early on.

The Three Metrics, In Detail

Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible element in the viewport, usually a hero image, a large block of text, or a background image, to fully render on screen. It answers the question "how long did the user wait before the main content appeared?"

• Good: under 2.5 seconds
• Needs Improvement: between 2.5 and 4 seconds
• Poor: over 4 seconds

The most common causes of poor LCP are slow server response times, render blocking CSS and JavaScript, unoptimized or unpreloaded images, and slow font loading that delays text rendering.

Interaction to Next Paint (INP)

INP replaced First Input Delay as the official responsiveness metric in March 2024. Where FID only measured the delay before the browser started processing a user's first interaction, INP measures the full lifecycle of every interaction across the page visit. It captures the time from when a user interacts (clicking a button, tapping a menu, typing in a field) to when the browser visually updates the screen in response.

• Good: under 200 milliseconds
• Needs Improvement: between 200 and 500 milliseconds
• Poor: over 500 milliseconds

INP is often the hardest of the three metrics to fix, because it usually points to JavaScript architecture: long running tasks blocking the main thread, excessive third party scripts, or heavy client side rendering that leaves the browser too busy to respond to input.

Cumulative Layout Shift (CLS)

CLS measures visual stability, specifically how much visible content unexpectedly shifts position while a page loads or is used. Tapping a button only to have an ad load above it and push everything down is a familiar example of poor CLS.

• Good: under 0.1
• Needs Improvement: between 0.1 and 0.25
• Poor: over 0.25

CLS problems usually come from images or embeds without defined width and height attributes, web fonts that cause a visible swap once they load, ads or embeds injected without reserved space, and content dynamically inserted above existing content.

Field Data Versus Lab Data

This distinction matters more than most guides make clear. Core Web Vitals, as an official ranking and reporting signal, are based on field data: real measurements collected from actual Chrome users visiting your site. This comes from the Chrome User Experience Report, commonly called CrUX.

Lab data, the kind you get from running Lighthouse in Chrome DevTools or a manual PageSpeed Insights test, is useful for diagnosis but is not what determines your official Core Web Vitals status. A page can score well in a Lighthouse test on a development machine and still fail its real world assessment, because a test environment does not reflect the mix of devices, network conditions, and browsing behavior that real visitors bring.

Google evaluates Core Web Vitals at the 75th percentile of real user visits over a rolling 28 day window. In plain terms, at least 75 percent of visits to a page need to hit the "good" threshold for that page to pass. This is a deliberately strict bar. It is not enough for a site to be fast on average.

Core Web Vitals in Google Search Console

Inside Search Console, Core Web Vitals sit under the Experience section in the left hand navigation. The report shows two separate summary charts, one for Mobile and one for Desktop, because performance differs across device types and Google evaluates them independently.

Each summary chart groups your URLs into three statuses: Good, Needs Improvement, and Poor.

Clicking "Open report" takes you deeper. Search Console does not list every URL one by one. It groups similar pages together, for example all product pages or all blog post templates, because pages built from the same template tend to share performance characteristics. If one group is failing, the cause is often template level or site wide rather than a single page.

Within each report you will find a historical trend chart, a breakdown by specific issue such as "LCP issue: longer than 2.5s (mobile)," and a table of example URLs for each issue.

A URL group's overall status defaults to whichever individual metric performs worst. If a group has good LCP and INP but poor CLS, the entire group is labeled Poor. Fixing two out of three metrics still leaves you failing until the third is addressed.

Search Console sometimes shows "No data available" for a URL or group. This usually means there is not enough real user traffic on those pages for CrUX to generate reliable field data. In that case, Google may report at the origin level (your whole domain) instead, or you can use PageSpeed Insights for a page level check.

Core Web Vitals and Bing Webmaster Tools

This is where a lot of confusion happens, because people assume Bing has a direct equivalent to Search Console's Core Web Vitals report. At the time of writing, it does not offer one with the same LCP, INP, and CLS breakdown.

Instead, page speed and broader technical health issues surface through Bing Webmaster Tools' Site Scan feature, which works more like a general technical SEO audit than a Core Web Vitals specific report. A Site Scan crawls the site the way Bingbot would and flags issues such as slow loading pages, broken links and redirect chains, missing or duplicate titles and meta descriptions, missing image alt attributes, duplicate content, mobile friendliness problems, and blocked pages.

Results are grouped by severity (low, moderate, high) rather than by the Core Web Vitals metric structure Google uses. Bing does care about page experience in principle, but its reporting is broader and less granular. If you need precise LCP, INP, or CLS numbers, Search Console and the CrUX based tools built on top of it, like PageSpeed Insights, remain the primary sources, even for sites that also care about Bing visibility.

In short, do not expect Bing Webmaster Tools to replace Search Console for Core Web Vitals monitoring. Use Search Console for metric level data, and use Bing's Site Scan as a broader technical health check.

How to Fix Each Metric

For LCP: compress and properly size images, use modern formats like WebP or AVIF, preload the largest above the fold image, minimize render blocking CSS and JavaScript, and improve server response times through better hosting or caching.

For INP: break up long JavaScript tasks so the browser can respond to input sooner, defer or remove unnecessary third party scripts, avoid heavy client side rendering for content that could be server rendered, and reduce the total JavaScript executing on page load.

For CLS: set explicit width and height attributes on images, videos, and embeds, reserve space for ads and dynamically injected content before it loads, and use font-display: swap carefully so text does not visibly reflow once custom fonts finish loading.

Why This Matters

Core Web Vitals have been a page experience ranking signal since 2021. They are not the deciding factor in a competitive results page, where content quality and relevance still carry far more weight, but between two similarly strong pages, the faster and more stable one has an edge. Beyond rankings, slow and unstable pages frustrate real visitors, and frustrated visitors convert less and leave sooner.

Closing

Core Web Vitals are three specific, measurable things: how fast your main content appears, how quickly the page responds when someone interacts with it, and how visually stable it stays while doing both. Check Search Console regularly, understand that Bing's reporting works differently, and fix whichever metric is failing worst first. If you want help diagnosing a slow or unstable site, our SEO services include a technical review of this kind.