Core Web Vitals: How to Measure and Improve Them

· By Marcus Ehrlich · SEO
Responsive website design mockup showing mobile phone, tablet, and laptop with performance metrics

Your website might rank on page one today. But if it loads slowly, stutters during clicks, or jumps around while content pops in, Google has a measurable reason to push you down. That reason has a name: Core Web Vitals.

I first saw Core Web Vitals tank a client’s traffic in 2021 when Google rolled out the page experience update. A travel booking site I was consulting for lost 23% of organic traffic in six weeks — not because their content got worse, but because their LCP ballooned to 4.8 seconds after a redesign. We fixed it in two sprints. Traffic recovered in three weeks.

This guide covers what Core Web Vitals are, how to measure them accurately, and the specific fixes that move the needle — based on what I’ve seen work across dozens of sites.

What Are Core Web Vitals?

Core Web Vitals are three specific metrics that Google uses to evaluate real-world user experience on your website. They measure loading speed, interactivity, and visual stability — the three things users notice most when a page feels “fast” or “broken.”

Here are the three metrics and their thresholds:

Metric What It Measures Good Needs Improvement Poor
LCP (Largest Contentful Paint) How fast the main content loads < 2.5s 2.5s – 4.0s > 4.0s
INP (Interaction to Next Paint) How fast the page responds to clicks/taps < 200ms 200ms – 500ms > 500ms
CLS (Cumulative Layout Shift) How much the layout shifts unexpectedly < 0.1 0.1 – 0.25 > 0.25

Google evaluates these at the 75th percentile of real user visits. That means 75% of your visitors need to have a “good” experience for your page to pass. One slow connection from a rural area can drag your score down.

Key insight: Only 48% of mobile pages pass all three Core Web Vitals metrics, according to the 2025 Web Almanac. If you get all three into “good” territory, you’re already ahead of half the web.

Why Core Web Vitals Matter for SEO

Core Web Vitals are a confirmed Google ranking factor — part of the broader “page experience” signal. But let’s be honest about their weight: content relevance and backlinks still matter more. CWV won’t save thin content, and fixing them won’t outrank a domain with 10x your authority.

Where they do make a difference:

  • Tie-breaking situations: When two pages are equally relevant, the faster one wins
  • User behavior signals: Faster pages have lower bounce rates, which indirectly strengthens rankings
  • Conversion impact: Vodafone Italy reported an 8% sales increase after improving LCP. Every 100ms of load time matters for the bottom line

The real value isn’t just SEO. It’s the compounding effect: faster pages → better engagement → lower bounce → higher conversions → stronger ranking signals. It’s a flywheel, not a checkbox.

How to Measure Core Web Vitals

There are two types of data, and understanding the difference is critical:

Data Type Source What It Tells You Used by Google for Rankings?
Field data (Real User Monitoring) Chrome User Experience Report (CrUX) How real visitors experience your site Yes
Lab data (Synthetic Testing) Lighthouse, WebPageTest How your site performs under controlled conditions No

Google ranks based on field data only. Lab data is useful for debugging, but your Lighthouse score isn’t what Google sees in Search Console.

Step 1: Check Google Search Console

Go to Experience → Core Web Vitals in Google Search Console. This report groups your URLs into three buckets — Good, Needs Improvement, and Poor — based on CrUX field data with a 28-day rolling window.

Start here because this is the truth. If Search Console says you’re green, you’re fine. If it’s yellow or red, that’s your priority list.

Step 2: Diagnose with PageSpeed Insights

Paste a specific URL into PageSpeed Insights. You’ll get both field data (if available) and lab data with specific recommendations. Focus on the “Opportunities” and “Diagnostics” sections — they tell you exactly what to fix and the estimated impact.

Step 3: Deep Dive with Chrome DevTools

For technical debugging, open Chrome DevTools → Performance tab → Record a page load. This shows you the exact timeline of rendering, JavaScript execution, and layout shifts. It’s the most granular view you can get.

Pro tip: Always test on mobile with throttled CPU (4x slowdown) and a “Fast 3G” network profile. Desktop scores are almost always better than mobile, and Google evaluates mobile-first.

How to Improve LCP (Largest Contentful Paint)

LCP is the hardest metric to pass — only 62% of mobile pages achieve “good” scores. The LCP element is usually the largest image or text block visible in the viewport when the page first loads.

Common LCP elements: hero images, banner images, large heading text blocks, featured videos.

Fix 1: Optimize the LCP Image

  • Use modern formats: WebP (30% smaller than JPEG) or AVIF (50% smaller)
  • Add fetchpriority="high" to the LCP image tag so the browser loads it first
  • Add a <link rel="preload"> in the <head> for the hero image
  • Size images to the display size — don’t serve a 3000px image for an 800px container

Fix 2: Eliminate Render-Blocking Resources

  • Inline critical CSS (the styles needed for above-the-fold content)
  • Defer non-critical CSS with media="print" and swap on load
  • Move JavaScript to the bottom or use defer/async attributes

Fix 3: Improve Server Response Time

  • Target a Time to First Byte (TTFB) under 800ms
  • Use a CDN to serve assets from edge servers close to your users
  • Enable server-side caching for dynamic pages
  • Consider upgrading your hosting if TTFB consistently exceeds 1 second

How to Improve INP (Interaction to Next Paint)

INP replaced First Input Delay (FID) in March 2024 as the official responsiveness metric. It measures the delay between a user interaction (click, tap, keypress) and the next visual update — across all interactions during a visit, not just the first one.

Fix 1: Reduce Main Thread Blocking

JavaScript running on the main thread is the number one cause of poor INP. When JS is executing, the browser can’t respond to user input.

  • Break long tasks (> 50ms) into smaller chunks using requestIdleCallback() or scheduler.yield()
  • Defer non-critical third-party scripts (analytics, chat widgets, social embeds)
  • Remove unused JavaScript — audit with Chrome DevTools Coverage tab

Fix 2: Optimize Event Handlers

  • Keep event handler code fast — avoid heavy DOM manipulation on click
  • Use requestAnimationFrame() for visual updates triggered by interactions
  • Debounce scroll and resize handlers

Fix 3: Reduce DOM Size

Pages with more than 1,500 DOM elements see significantly worse INP scores. Simplify your HTML structure, avoid deeply nested elements, and lazy-load content below the fold.

How to Improve CLS (Cumulative Layout Shift)

CLS is the most “fixable” metric — 81% of mobile pages already pass. Layout shifts happen when visible elements move after they’ve been rendered, usually because something loaded late and pushed content around.

Fix 1: Set Explicit Dimensions on Media

  • Always include width and height attributes on <img> and <video> tags
  • Use CSS aspect-ratio for responsive containers
  • Reserve space for ads and embeds with min-height containers

Fix 2: Stabilize Web Fonts

  • Self-host fonts instead of loading from third-party CDNs
  • Use font-display: swap with a size-matched fallback font
  • Preload critical font files: <link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

Fix 3: Handle Dynamic Content Carefully

  • Cookie consent banners should overlay content, not push it down
  • Lazy-loaded images need placeholder containers with correct dimensions
  • Avoid injecting content above existing content after page load

A Prioritized Optimization Checklist

Not all fixes are equal. Here’s how I prioritize based on typical impact:

Priority Fix Metric Affected Typical Impact Effort
1 Add fetchpriority=”high” to LCP image LCP 0.3-1.0s improvement 5 minutes
2 Set width/height on all images CLS 0.05-0.15 improvement 30 minutes
3 Defer non-critical JS INP + LCP 100-300ms improvement 1-2 hours
4 Convert images to WebP/AVIF LCP 0.5-1.5s improvement 1-2 hours
5 Preload critical fonts CLS + LCP 0.1-0.3s improvement 30 minutes
6 Enable CDN LCP 0.3-0.8s improvement 1-2 hours
7 Break long JS tasks INP 50-200ms improvement 2-4 hours
8 Inline critical CSS LCP 0.2-0.5s improvement 2-3 hours

Start with items 1-3. They take less than two hours total and typically solve 60-70% of Core Web Vitals issues.

Monitoring After Optimization

Fixing Core Web Vitals once isn’t enough. New deployments, plugin updates, and content changes can break what you’ve fixed. Set up ongoing monitoring:

  1. Google Search Console: Check the CWV report weekly. It updates with a 28-day rolling window, so changes take time to reflect
  2. Real User Monitoring (RUM): Add the web-vitals JavaScript library to your site to capture field data in real time
  3. Automated Lighthouse CI: Run Lighthouse in your deployment pipeline to catch regressions before they go live
  4. Performance budgets: Set thresholds (e.g., “LCP must stay under 2.0s”) and alert when they’re exceeded

I run weekly CWV checks for all client sites. When a metric degrades, we catch it within days instead of discovering it months later in a traffic drop.

Frequently Asked Questions

Do Core Web Vitals directly affect Google rankings?

Yes, Core Web Vitals are a confirmed ranking factor as part of Google’s page experience signal. However, content relevance and authority still carry more weight. CWV matter most in competitive situations where two pages are equally relevant — the faster page gets the edge.

How long does it take for CWV improvements to affect rankings?

Google uses a 28-day rolling window of field data from CrUX. After fixing issues, expect 4-6 weeks before Google Search Console reflects the improvement, and another 2-4 weeks before you see ranking changes. Total timeline: about 2-3 months from fix to visible SEO impact.

What replaced First Input Delay (FID)?

Interaction to Next Paint (INP) replaced FID as the official responsiveness metric in March 2024. Unlike FID, which only measured the first interaction, INP tracks all interactions throughout a page visit and reports the worst one. This gives a more complete picture of page responsiveness.

Can I pass Core Web Vitals on a shared hosting plan?

It’s possible but difficult. Shared hosting often has slow server response times (high TTFB), which directly impacts LCP. If your TTFB consistently exceeds 800ms, consider upgrading to managed hosting or a VPS. Pairing a CDN with shared hosting can partially offset the slower origin server.

Do Core Web Vitals affect all pages or just the homepage?

Core Web Vitals are evaluated on a per-page basis. Google groups similar URLs together in Search Console (e.g., all product pages), but each page type can have different scores. Fix your highest-traffic pages first for maximum impact, then work through lower-traffic templates.

Key Takeaways

Core Web Vitals aren’t just a technical checkbox — they’re a proxy for how real users experience your site. Here’s your action plan:

  1. Check Google Search Console first — it shows what Google actually sees
  2. Fix the quick wins — fetchpriority, image dimensions, and deferred JS solve most issues in under two hours
  3. Focus on mobile — that’s what Google indexes and evaluates first
  4. Monitor continuously — one deploy can undo weeks of optimization work
  5. Don’t obsess over perfect scores — “good” thresholds are the target, not 100/100 on Lighthouse

The sites that consistently pass CWV aren’t the ones with the fanciest tech stacks. They’re the ones that treat performance as part of the overall SEO strategy — not an afterthought.

Marcus Ehrlich

Written by

Marcus Ehrlich

Web analyst and digital marketing strategist based in Berlin. 10+ years turning raw data into growth. Former head of analytics at a top European e-commerce platform. Now helping businesses decode their digital footprint through Faqirs Digital.

Leave a Comment

Your email address will not be published. Required fields are marked *