What Are Core Web Vitals and How Do You Measure and Improve Them?

Core Web Vitals are three metrics Google uses to measure real page experience: LCP (loading), INP (interactivity), and CLS (visual stability). Each has published thresholds — good, needs improvement, poor — and each maps to a small set of common causes with known fixes. You measure them two ways: lab data from a tool like Lighthouse (a simulated run) and field data from real visitors (Chrome UX Report, Search Console). Lab data tells you what to fix; field data tells you whether it worked.

The three metrics and what each one measures

INP replaced FID (First Input Delay) as the interactivity metric. FID only measured the delay before the browser started processing the first interaction; INP samples interactions across the whole visit and reports a high-percentile value, so it catches slow responses that FID missed. If you see FID in older reports, treat INP as the current target.

Thresholds are evaluated at the 75th percentile of page loads, segmented by mobile and desktop. A page passes only when 75% of real visits hit the "good" band for all three metrics.

How to measure: lab data vs. field data

These answer different questions, and you need both.

Lab data (Lighthouse, PageSpeed Insights' "Analyze" tab) — a single simulated load on a throttled connection. It's reproducible, so it's good for debugging and for comparing before/after a fix. It is not what your users experience.

Field data (Chrome UX Report via PageSpeed Insights' top section, or Search Console's Core Web Vitals report) — aggregated from real Chrome users over the past 28 days. This is what Google's ranking systems actually see. It can be empty for low-traffic pages, in which case you have no field signal yet.

A practical workflow:

1. Run PageSpeed Insights on the URL. Read the field data first — if the page passes in the field, lab warnings are lower priority.
2. If field data is failing or missing, use the Lighthouse section to find the specific cause.
3. Fix, deploy, then re-check field data after the 28-day window rolls over. Lab scores update immediately; field data does not.

Repolog runs Core Web Vitals from Lighthouse (FCP, LCP, TBT, CLS, Speed Index) on mobile emulation inside a real headless browser load, scored against Google's thresholds, and returns a ranked report in about a minute with no signup — one homepage per day on the free scan. That's useful for a fast baseline; you still want field data to confirm real-world impact.

Common causes and fixes

LCP is slow

The usual culprits, in rough order of frequency:

• The LCP element is an unoptimized image. Serve it as WebP/AVIF, size it correctly, and add fetchpriority="high" to the hero image. Don't lazy-load the LCP image.
• Render-blocking CSS or fonts. Inline critical CSS, defer the rest, and preload the primary font file.
• Slow server response (high TTFB). LCP can't be faster than the server's first byte. Check caching, CDN coverage, and database queries on the critical path.
• Client-side rendering. If the hero content only appears after a JS bundle executes, the browser paints late. Server-render or statically generate the above-the-fold content.

INP is high

• Long tasks on the main thread. Break up JavaScript that runs for more than 50ms; yield to the browser between chunks.
• Heavy third-party scripts — tag managers, chat widgets, analytics. Load them after interaction or in a worker where possible.
• Expensive event handlers. Debounce input handlers and avoid layout reads/writes inside them.

CLS is high

• Images and iframes without dimensions. Always set width and height (or an aspect-ratio box) so the browser reserves space.
• Ads, embeds, and banners injected above existing content. Reserve a fixed slot.
• Web fonts swapping and reflowing text. Use font-display: optional or swap with a matched fallback metric.
• Late-injected DOM (cookie bars, promos) that pushes content down. Overlay instead of inserting into flow.

Where Core Web Vitals fit in a broader audit

Core Web Vitals are one input among several, and they interact with the rest. A page can pass all three metrics and still fail on SEO fundamentals (missing titles, broken heading hierarchy, no canonical), accessibility (contrast, form labels, ARIA), or security (missing HSTS, exposed .env). Repolog's scan bundles these: 60+ checks across SEO, performance, accessibility (axe-core against WCAG 2 rules, reported to the failing element), security (19 read-only checks including header and file-exposure tests), and AI readiness (18 checks covering GPTBot/ClaudeBot/PerplexityBot access in robots.txt, JSON-LD, sitemap.xml, llms.txt, and FAQ patterns). Each issue comes with its fix.

The reason to look at them together: a fix for one can regress another. Deferring a script to improve INP can delay the LCP element. Adding a consent banner for compliance can introduce CLS. Running the checks in the same browser load, as Repolog does, makes those trade-offs visible in one report instead of three.

Quick decision guide

• Just want to know if you pass? PageSpeed Insights field data, or Search Console's Core Web Vitals report.
• Need to debug a specific failing metric? Lighthouse in Chrome DevTools, with the performance trace open.
• Want a ranked list of everything to fix across SEO, speed, accessibility, security, and AI readiness, with the fix attached? Run a scan on your homepage — Repolog's free audit takes about a minute with no signup, and the paid tiers (7-day free trial, $0 due today) add keyword research runs, keyword-to-page mapping, and Search Console integration for cannibalization checks.