Google Search Console Core Web Vitals: How to Find, Fix & Monitor Your Scores

Core Web Vitals are Google ranking signals — and Search Console tells you exactly which pages are failing them.

Since Google's Page Experience update, Core Web Vitals directly influence where your pages rank. Poor LCP, INP, or CLS scores can cost you positions even if your content is excellent. The good news: Google Search Console shows you every failing URL, grouped by issue type, so you can fix them systematically.

This guide covers everything you need: where to find the Core Web Vitals report in GSC, what each metric measures, how to interpret the data, and how to fix the most common issues.

What Are Core Web Vitals?

Core Web Vitals are three user experience metrics that Google uses as ranking signals. They measure loading performance, interactivity, and visual stability.

| Metric | What It Measures | Good | Needs Improvement | Poor | |--------|-----------------|------|-------------------|------| | LCP (Largest Contentful Paint) | Loading speed — how fast the main content appears | ≤ 2.5s | 2.5–4.0s | > 4.0s | | INP (Interaction to Next Paint) | Interactivity — how fast pages respond to user input | ≤ 200ms | 200–500ms | > 500ms | | CLS (Cumulative Layout Shift) | Visual stability — how much the page layout shifts | ≤ 0.1 | 0.1–0.25 | > 0.25 |

Note: INP replaced FID (First Input Delay) as an official Core Web Vital in March 2024. If you see older reports referencing FID, they're measuring a different (and now deprecated) metric.

All three must score "Good" for a URL to pass the Core Web Vitals assessment.

Where to Find Core Web Vitals in GSC

Log into Google Search Console
Select your property in the left dropdown
In the left sidebar, under Experience, click Core Web Vitals

You'll see two separate reports: one for Mobile and one for Desktop. Both matter — Google uses mobile-first indexing, so the Mobile report is the priority.

Don't see the Core Web Vitals section? Your site may not have enough real-user data yet. GSC uses Chrome User Experience Report (CrUX) data, which requires a minimum threshold of real users visiting your site. New or very low-traffic sites may not have enough data to populate the report.

Understanding the Core Web Vitals Report

Each report (Mobile and Desktop) shows a chart with three categories:

🟢 Good — URLs with all three metrics passing
🟡 Needs Improvement — At least one metric in the "Needs Improvement" range
🔴 Poor — At least one metric in the "Poor" range

The Issue Groups Table

Below the chart, you'll see a table of specific issues found on your site. Each row shows:

| Column | What It Means | |--------|---------------| | Issue | The specific metric and threshold (e.g., "LCP issue: longer than 4s") | | Status | Failing or passing | | URLs | Number of URLs affected |

Click any issue to see the specific URLs affected. Click a specific URL to open the URL Inspection tool for detailed analysis.

Field Data vs. Lab Data

GSC Core Web Vitals uses field data (real user measurements from Chrome users visiting your site). This is different from lab data you'd get from PageSpeed Insights or Lighthouse.

Key differences:

Field data (CrUX/GSC): What real users actually experience on your site. Aggregated over a 28-day rolling window. The data that affects rankings.
Lab data (PageSpeed/Lighthouse): What a simulated test run measures in a controlled environment. Useful for debugging but doesn't directly reflect ranking impact.

Always prioritize fixing what CrUX/GSC field data reports — that's what Google uses for ranking.

LCP: Largest Contentful Paint

LCP measures how long it takes for the largest visible element on the page to load. This is usually:

A hero image or banner photo
A large heading or block of text
An embedded video thumbnail

Target: Under 2.5 seconds.

Common LCP Issues in GSC

"LCP issue: longer than 4s" — Critical, affects rankings
"LCP issue: longer than 2.5s" — Needs improvement

How to Fix Slow LCP

1. Optimize and compress images

Convert images to WebP or AVIF format (30-50% smaller than JPEG/PNG)
Use proper image dimensions (don't serve 2000px images in a 400px slot)
Use tools: Squoosh, ImageOptim, or build-step tools like sharp

2. Add fetchpriority="high" to your LCP image

<img src="hero.webp" fetchpriority="high" alt="Hero image" />

This tells the browser to prioritize loading this image above other resources.

3. Preload the LCP image

<link rel="preload" as="image" href="hero.webp" fetchpriority="high" />

4. Eliminate render-blocking resources

Move non-critical CSS to <link media="print"> with a JavaScript swap
Defer non-critical JavaScript with defer or async
Remove or inline critical CSS

5. Improve server response time (TTFB)

Use a CDN (Cloudflare, Fastly, BunnyCDN)
Enable server-side caching
Upgrade hosting if shared hosting is too slow

6. Use lazy loading correctly

Apply loading="lazy" to below-the-fold images — not to your LCP image
Common mistake: lazy-loading the hero image, which delays LCP significantly

INP: Interaction to Next Paint

INP measures responsiveness — how quickly the page reacts after a user interaction (click, tap, keyboard input). It replaced FID in March 2024 because it captures all interactions during a page visit, not just the first one.

Target: Under 200ms.

Common INP Issues in GSC

"INP issue: longer than 500ms" — Poor
"INP issue: longer than 200ms" — Needs improvement

How to Fix High INP

1. Reduce JavaScript execution time

Identify long tasks with Chrome DevTools → Performance panel
Look for tasks blocking the main thread for more than 50ms
Break up long tasks using scheduler.yield() or setTimeout chunking

2. Minimize third-party scripts

Analytics, chat widgets, ad scripts, and tag managers often cause INP issues
Audit third-party scripts: do you need all of them?
Load non-critical scripts with async or defer them after user interaction

3. Optimize event handlers

Remove heavy synchronous work from click/tap handlers
Debounce scroll and resize handlers
Move computation off the main thread using Web Workers

4. Reduce DOM size

Large DOMs (10,000+ nodes) slow down all browser rendering operations
Use virtual scrolling for long lists
Remove hidden/unused DOM elements

5. Update your JavaScript frameworks

React 18, Vue 3, and Angular 17+ all have improved hydration strategies
Enable concurrent rendering features where available

CLS: Cumulative Layout Shift

CLS measures visual stability — how much page content unexpectedly shifts after it initially loads. The classic culprit: ads or images that load in and push text down as you're reading.

Target: Under 0.1.

Common CLS Issues in GSC

"CLS issue: more than 0.25" — Poor
"CLS issue: more than 0.1" — Needs improvement

How to Fix High CLS

1. Always set explicit width and height on images and videos

<!-- Bad: browser doesn't know space to reserve -->
<img src="photo.jpg" alt="Photo" />

<!-- Good: browser reserves exact space before image loads -->
<img src="photo.jpg" width="800" height="450" alt="Photo" />

Or use CSS aspect-ratio:

img { aspect-ratio: 16/9; width: 100%; }

2. Reserve space for ads and embeds

.ad-slot {
  min-height: 250px; /* Reserve space before ad loads */
  width: 300px;
}

3. Avoid inserting content above existing content

Don't inject banners, cookie notices, or announcements above the fold after page load
If you must show a banner, always reserve its space upfront (even before it appears)

4. Use transform animations instead of layout-triggering properties

/* Bad: triggers layout recalculation */
.element { transition: top 0.3s; }

/* Good: uses GPU compositing, no layout shift */
.element { transition: transform 0.3s; }

5. Fix web font loading

Add font-display: optional or font-display: swap to your @font-face declarations
Preload critical fonts:

<link rel="preload" as="font" href="font.woff2" crossorigin />

How to Work Through the GSC Core Web Vitals Report

Step 1: Start with Mobile, focus on "Poor" URLs first

Mobile issues affect more users and are Google's primary ranking signal. "Poor" URLs are actively hurting your rankings — fix them before "Needs Improvement."

Step 2: Click the issue group → identify patterns

When you click into an issue (e.g., "LCP issue: longer than 4s"), look at the list of affected URLs:

Are they all on the same template (e.g., all blog posts)?
Are they mostly homepage and landing pages?
Or is it scattered across the whole site?

Template-level fixes (one change, many pages fixed) give you the best ROI.

Step 3: Pick one URL and diagnose with PageSpeed Insights

Take an affected URL and run it through PageSpeed Insights — it shows both field data (CrUX) and lab data (Lighthouse), plus specific diagnostics for what's causing the issue.

Step 4: Fix at the template level

If all blog posts have slow LCP because of unoptimized featured images, fix the image handling in your blog post template — one fix that clears all affected URLs.

Step 5: Validate the fix in GSC

After deploying fixes:

Go back to GSC → Core Web Vitals
Click the issue → scroll down → click "Validate Fix"
Google re-crawls the affected pages and confirms whether the issue is resolved
CrUX data updates on a 28-day rolling window, so full validation takes time

Important: GSC marks an issue as "Passed" based on re-crawl validation, but the field data metrics in the CrUX report take 28 days to fully reflect improvements.

Core Web Vitals vs. PageSpeed Score

These measure different things — don't confuse them:

| | Core Web Vitals (GSC) | PageSpeed Score | |-|--------------------------|---------------------| | Source | Real user data (CrUX) | Lab simulation (Lighthouse) | | Affects rankings | Yes | No | | Updates | 28-day rolling window | Instant (on each run) | | Use for | Knowing your ranking impact | Diagnosing specific issues | | Score type | Good / Needs Improvement / Poor | 0–100 numeric |

You can have a PageSpeed score of 95 and still fail Core Web Vitals in the field — or vice versa. Always check both, but prioritize fixing what real users experience.

Core Web Vitals Quick Reference

| Problem | Likely Cause | Quick Fix | |---------|-------------|-----------| | Slow LCP on image-heavy pages | Unoptimized hero images | Convert to WebP + fetchpriority="high" | | Slow LCP across all pages | Slow server (TTFB) | Add CDN, enable caching | | High INP on pages with ads | Third-party scripts blocking main thread | Defer/lazy-load ad scripts | | High INP on React/Next.js apps | Heavy hydration | Enable React 18 concurrent features | | High CLS on blog posts | Images without dimensions | Add width + height to all <img> tags | | High CLS from ads | No reserved ad space | Add min-height to ad containers | | High CLS from cookie banners | Banner injected after load | Reserve space or slide in from bottom |

Frequently Asked Questions

How often does Google update Core Web Vitals data in Search Console?
The Core Web Vitals report uses a 28-day rolling window of CrUX (Chrome User Experience Report) data. Updates happen roughly daily, but since it's a rolling window, you won't see dramatic changes overnight. After implementing fixes, expect to see gradual improvement over 2–4 weeks as the new data replaces the old.

Does failing Core Web Vitals mean I'll drop in rankings?
Failing Core Web Vitals is a negative ranking signal, but it's one of many factors. You can still rank with poor Core Web Vitals if your content is significantly more relevant and authoritative than competitors. However, when two pages are roughly equal in other factors, Core Web Vitals can be the tiebreaker. For competitive niches, fixing them is important.

Why does my Core Web Vitals report show "Not enough data" for my site?
The report requires a minimum number of real Chrome user visits to your site before CrUX data is populated. If your site has low traffic, or it's new, you may not meet this threshold. Use PageSpeed Insights with your URL to check for any available field data at the URL level. Focus on lab data (Lighthouse) until field data is available.

My PageSpeed score is 90+ but GSC still shows Core Web Vitals issues. Why?
PageSpeed/Lighthouse uses lab data from a simulated test environment. Real users may experience different conditions: slower devices, slower network connections, third-party ads loading, or personalized content. The field data in GSC reflects what actual Chrome users experience visiting your site — it's much more reliable for understanding your real ranking impact.

Do I need to fix Core Web Vitals on every single page?
Focus on your highest-traffic and highest-value pages first (homepage, top landing pages, top blog posts). For template-based sites, fixing the template often resolves issues across hundreds of pages at once. GSC groups issues by type so you can see which pages share the same root cause — use that to prioritize template-level fixes.

Should I fix mobile or desktop Core Web Vitals first?
Start with mobile. Google uses mobile-first indexing, meaning it primarily uses the mobile version of your site for ranking. Mobile Core Web Vitals have the most direct ranking impact. That said, desktop fixes are often simpler (no image resizing constraints, faster network assumptions) so you might tackle them in parallel.

For a complete overview of all GSC features, start with the Ultimate Google Search Console Guide. If your pages are slow to get indexed, the Google Search Console URL Inspection Tool guide shows you how to request priority crawling.