AXOX Hub Hub
Seo Aug 9, 2026 6 min read

Core Web Vitals: What They Actually Mean and How to Test Yours

Learn how to check your website's Core Web Vitals, interpret LCP, INP, and CLS scores, and fix the most common causes of poor performance.

If your site feels fast to you but Google Search Console keeps flagging "poor" URLs, you're not imagining anything — you're just testing it wrong. Core Web Vitals aren't measured by how a page feels on your dev machine with a fast connection and an empty cache. They're measured by real users, on real devices, often on mediocre mobile networks. Here's how to actually check them, read them correctly, and fix what's broken.

What Core Web Vitals Actually Measure

Google currently tracks three metrics as its Core Web Vitals:

  • LCP (Largest Contentful Paint) — how long it takes for the largest visible element (usually a hero image, banner, or heading block) to render. Target: under 2.5 seconds.
  • INP (Interaction to Next Paint) — how responsive your page is when a user clicks, taps, or types. Replaced First Input Delay (FID) in March 2024. Target: under 200 milliseconds.
  • CLS (Cumulative Layout Shift) — how much visual content jumps around while loading. Target: under 0.1.

These three thresholds determine whether a page is rated "Good," "Needs Improvement," or "Poor" — and that rating can influence how your pages perform in Google's ranking systems, particularly for mobile search.

Step 1: Check Real-User Data First

Before you touch any code, find out if this is actually a problem for real visitors. Lab tests (like Lighthouse) simulate a single session — they don't tell you what's happening across your actual traffic.

Where to look

  1. Google Search Console → Core Web Vitals report. This shows URL groups flagged as Poor, Needs Improvement, or Good, based on the CrUX (Chrome User Experience Report) dataset — real Chrome users, aggregated over 28 days.
  2. PageSpeed Insights. Enter any URL and it will show both field data (real users, if enough traffic exists) and lab data (a simulated Lighthouse run). If your site doesn't have enough Chrome traffic for field data, you'll only see the lab score — treat that as an estimate, not gospel.
  3. Chrome DevTools → Performance panel. Record a page load locally and inspect the timeline for LCP markers, layout shift regions, and long tasks blocking the main thread.

If Search Console shows a batch of URLs as "Poor" for LCP, don't assume it's the whole site — click into the report and see which templates or page types are affected. Product pages with heavy image carousels behave very differently from a lightweight blog post template.

Step 2: Test on Mobile, Not Desktop

Most Core Web Vitals problems live on mobile. Desktop connections and CPUs are forgiving; a mid-range Android phone on 4G is not. When you run PageSpeed Insights or Lighthouse, always check the mobile score separately — it's usually meaningfully worse than desktop, and mobile is what Google's CrUX dataset weights most heavily for many sites. Practical tip: throttle your own testing. In Chrome DevTools, set network to "Slow 4G" and CPU throttling to "4x slowdown" before recording a Performance trace. That's a far more honest picture of what a real visitor experiences than an unthrottled localhost load.

Step 3: Diagnose the Root Causes by Metric

Slow LCP — usual suspects

  • Unoptimized hero images (serve WebP/AVIF, correct dimensions, no oversized originals)
  • No preconnect/preload hints for critical resources like fonts or the hero image
  • Render-blocking CSS or JavaScript in the <head>
  • Slow server response time (TTFB) — check this with an HTTP header checker to see caching headers and response times directly
  • Client-side rendering frameworks that delay meaningful paint until JS hydrates

Poor INP — usual suspects

  • Heavy JavaScript execution blocking the main thread during interaction
  • Third-party scripts (ads, chat widgets, analytics tags) firing synchronously
  • Large, unoptimized event handlers on scroll or click
  • Too many DOM nodes making style recalculation expensive

High CLS — usual suspects

  • Images and embeds without explicit width and height attributes
  • Web fonts causing a flash of unstyled text or a layout reflow (FOIT/FOUT)
  • Ads or dynamically injected banners pushing content down after load
  • Cookie consent banners or notification bars that shift the page on entry

Step 4: Check the Technical Layer Around the Page

Core Web Vitals problems aren't always about front-end code — sometimes they're structural. A few things worth ruling out:

  • Redirect chains. Each hop before the final page adds latency directly to your LCP and TTFB. Run a redirect checker on your key landing pages to confirm you're not sending users through two or three redirects before the actual page loads.
  • SSL/TLS handshake overhead. Misconfigured certificates or outdated TLS versions add connection delay. An SSL checker can confirm your certificate chain and protocol version are clean and not adding unnecessary round trips.
  • Response headers and caching. Missing Cache-Control or ETag headers mean repeat visitors re-download assets they should already have cached locally. Use an HTTP header checker on a few key URLs and static assets to confirm caching is actually configured correctly at the server or CDN level.

A Quick Field-vs-Lab Checklist

  • ☐ Checked Search Console's Core Web Vitals report for URL-level field data
  • ☐ Run PageSpeed Insights on both a homepage and a representative deep page (product, article, category)
  • ☐ Tested mobile specifically, with throttled network/CPU in DevTools
  • ☐ Identified which metric (LCP, INP, or CLS) is failing — not just "the score is low"
  • ☐ Checked server response headers and redirect paths on the affected URL
  • ☐ Re-tested after each fix — one change at a time, so you know what actually moved the needle

Step 5: Re-Test Regularly, Not Just Once

Core Web Vitals field data is a rolling 28-day average, so a fix you ship today won't show up in Search Console immediately — it takes time for enough real-user sessions to accumulate. Don't panic-check daily. Instead:

  1. Fix the highest-impact issue first (usually LCP on your top-traffic templates)
  2. Re-run PageSpeed Insights lab tests immediately to confirm the lab score improved
  3. Wait 2–4 weeks and check Search Console field data to confirm the real-user rating shifted
  4. Move to the next metric

Run your redirect paths, SSL setup, and response headers through the free tools at axoxhub.com before you start chasing front-end fixes — a slow server response or an extra redirect hop is often the quickest win before you touch a single line of CSS.

Try the free tool

Open Tool
← Back to Blog