Core Web Vitals Explained in Plain English

Marcus Hale

Performance Engineer

“A plain-English guide to Google Core Web Vitals - what each metric measures, why it affects rankings, the thresholds, and how to improve your scores.”

Executive Summary (Key Takeaways)

What They Are: Core Web Vitals are four specific performance metrics Google uses to measure the quality of a user's experience on your website. They are confirmed ranking factors - failing them places your site at a disadvantage compared to competitors who pass.
The Four Metrics: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), Cumulative Layout Shift (CLS), and Time to First Byte (TTFB). Each measures a different dimension of page quality.
The Stakes: Google's own research shows that when a site meets the Core Web Vitals thresholds, users are 24% less likely to abandon the page mid-load. Abandonment rate is directly correlated with bounce rate - which is a ranking signal.
The Good News: The highest-impact Core Web Vitals fixes (image optimization, lazy loading, adding image dimensions) are implementable without a developer on most platforms.

What Are Core Web Vitals?

Core Web Vitals are a set of four user experience metrics defined and measured by Google that quantify how fast, stable, and responsive a web page feels to real visitors. Since Google's 2021 Page Experience update, these metrics are confirmed ranking factors - websites that pass all four thresholds have a measurable ranking advantage over those that fail, all other factors being equal. They are measured from real user data collected by Chrome browsers across the internet.

Fig 1: The four confirmed Google page experience metrics

The phrase "core web vitals" sounds intimidatingly technical, but each metric is measuring something your customers experience every single day:

LCP measures how quickly the main content appears on screen - the moment when the page feels loaded
INP measures how quickly the page responds when you tap a button or click a link
CLS measures whether the page "jumps around" as it loads, moving text and buttons before you can read or click them
TTFB measures the initial server response speed

Google chose these four because they most directly correlate with user frustration and abandonment behavior.

Metric 1: Largest Contentful Paint (LCP)

LCP measures the time from when a visitor navigates to your page to when the largest visible element - usually your hero image or main heading block - finishes rendering. LCP represents the perceived load speed: the moment when the page content feels "there." Google's target is under 2.5 seconds. Above 4 seconds is classified as "Poor."

Think of LCP as the "main stage loading" metric. When you arrive on a webpage and see a white screen with a loading spinner for several seconds, then the main content appears - that delay is what LCP measures.

Fig 2: Why server speed (TTFB) directly delays LCP

What fails LCP most often:

Large, uncompressed hero images (the most common cause)
Render-blocking scripts that delay the browser from painting content
Slow server response (high TTFB) which delays everything downstream
CSS that blocks above-the-fold content from rendering

How to improve LCP:

Compress and resize your hero image. If your homepage banner is a 4MB JPEG, compress it to under 200KB as WebP. This single change often moves LCP from "Poor" to "Good."
Preload your LCP image. Add <link rel="preload" as="image" href="/hero.webp"> in your <head>. This tells the browser to download the image as its first priority.
Upgrade your hosting. If TTFB is above 600ms, your server is the bottleneck. Moving to a CDN-based host (Vercel, Netlify, Cloudflare Pages) can reduce TTFB to under 100ms.
Use a CDN. A Content Delivery Network serves your images from the server geographically closest to each visitor, dramatically reducing load time.

LCP targets:

Article data table
Score	Threshold
Good	Under 2.5 seconds
Needs Improvement	2.5–4 seconds
Poor	Over 4 seconds

Metric 2: Interaction to Next Paint (INP)

INP measures the responsiveness of your page to user interaction - specifically, the delay between a user tapping a button or clicking a link and the page visually changing in response. A high INP score means your page feels "laggy" or unresponsive. Google replaced First Input Delay (FID) with INP as a Core Web Vital in 2024 because INP more accurately measures ongoing interactivity throughout the entire page visit.

INP failures most commonly occur on JavaScript-heavy pages where the browser's main thread is occupied processing scripts and cannot respond promptly to user inputs.

What fails INP most often:

Heavy JavaScript frameworks loading too much code on the main thread
Long animation tasks that block the browser from responding to inputs
Third-party scripts (chat widgets, analytics, advertising scripts) with significant processing requirements
Slow event handlers (complex JavaScript running on every click or tap)

How to improve INP:

Reduce the size of your JavaScript bundle (code splitting)
Move non-critical scripts to web workers where possible
Defer non-essential JavaScript until after the user interacts
Remove or audit heavy third-party scripts

INP fixes typically require developer involvement - this is the most technical of the four metrics.

INP targets:

Article data table
Score	Threshold
Good	Under 200ms
Needs Improvement	200–500ms
Poor	Over 500ms

Metric 3: Cumulative Layout Shift (CLS)

CLS measures how much page elements move unexpectedly as a page loads. The most common experience of poor CLS: you go to tap a button, the page shifts as an image loads above it, and you accidentally tap something else. This is frustrating for users and penalized by Google. A CLS score above 0.1 is in the "Needs Improvement" range; above 0.25 is "Poor."

CLS is usually the easiest Core Web Vital to fix because it is typically caused by a small number of specific, identifiable issues.

What causes CLS most often:

Images without explicit width and height attributes (browser cannot reserve space before they load)
Late-loading ads that push content down when they appear
Font loading causing text to "jump" when the web font replaces the fallback font
Dynamically injected elements (cookie banners, chat widgets) that appear above existing content

How to fix CLS:

Add width and height to every image. This is the most impactful CLS fix for most sites:

<!-- Before (causes layout shift) -->
<img src="hero.webp" alt="Homepage hero">

<!-- After (no layout shift) -->
<img src="hero.webp" alt="Homepage hero" width="1200" height="600">

Reserve space for ads. Any ad slot that loads after the initial paint should have a fixed container with defined dimensions so the rest of the content does not shift when the ad loads.
Use font-display: swap for web fonts. This tells the browser to use the fallback font immediately and swap to the web font when it loads - the swap is fast enough to score well on CLS.
Delay cookie banners. Implement consent banners as overlays (not document flow insertions) that do not push content down.

CLS targets:

Article data table
Score	Threshold
Good	Under 0.1
Needs Improvement	0.1–0.25
Poor	Over 0.25

Metric 4: Time to First Byte (TTFB)

TTFB measures the time between a user requesting your page and their browser receiving the first byte of data from your server. It is the foundation metric - a slow TTFB delays everything else, including LCP. A TTFB above 800ms is classified as "Needs Improvement." Under 200ms is the target for well-engineered sites hosted on modern infrastructure.

TTFB is primarily a hosting and server architecture issue rather than a content or code issue.

What causes high TTFB:

Shared hosting plans where your server is under-resourced and handles too many simultaneous requests
WordPress generating pages dynamically from a database on every request without adequate caching
No CDN - all traffic routes to a single origin server regardless of the visitor's location
Unoptimized database queries on dynamic pages

How to improve TTFB:

Upgrade hosting. Move from shared hosting (TTFB 600–2,000ms) to managed WordPress hosting (200–400ms) or edge/CDN hosting for static sites (under 50ms).
Implement page caching. For WordPress, WP Rocket or W3 Total Cache serve pre-built HTML pages rather than regenerating on each request.
Add a CDN. Cloudflare's free plan caches content at edge locations worldwide, reducing TTFB for non-UK visitors significantly.
Use a static site generator. Next.js with static site generation pre-renders HTML at build time, achieving TTFB of 10–50ms on Vercel.

How to Check Your Core Web Vitals

Three ways to check (all free):

Google PageSpeed Insights (pagespeed.web.dev): Paste your URL for lab measurements and real-user field data where available. Shows pass/fail for each metric with specific recommendations.
Google Search Console: Navigate to Experience → Core Web Vitals. This shows aggregated field data from real Chrome users on your site over the past 28 days - the most accurate representation of how Google actually scores you.
Chrome DevTools: Open any page in Chrome, right-click → Inspect → Performance panel → Record your visit. Shows a detailed waterfall of when each resource loaded.

For all the technical fixes in context, see our complete technical SEO checklist. For how performance issues affect your bottom line, see our guide on why your website is so slow.

Frequently Asked Questions

Are Core Web Vitals the most important ranking factor?

No - Google is clear that Core Web Vitals are one of many ranking signals and that great content and strong authority will still outrank a slightly faster competitor. However, in competitive markets where content quality and authority are roughly equal between competitors, Core Web Vitals can be the differentiating factor. More importantly, poor Core Web Vitals create user experience problems that reduce conversions regardless of their ranking impact.

How long does it take to improve Core Web Vitals scores?

After implementing optimizations, lab scores (PageSpeed Insights) update immediately. Field data in Google Search Console reflects real user experience data from the past 28 days, so improvements take 4 to 6 weeks to appear in Search Console's Core Web Vitals report. Ranking changes resulting from Core Web Vitals improvements typically appear 4 to 8 weeks after the field data improves.

My desktop score is great but mobile is poor - does that matter?

Yes - mobile performance is what Google primarily measures for ranking purposes. Google uses mobile-first indexing, meaning it evaluates and ranks your site based on the mobile version. A site scoring 95 on desktop and 45 on mobile is ranked based on the 45. Mobile optimization must be the priority. Common causes of the gap: large images that mobile connections load slowly, render-blocking scripts that mobile processors cannot execute quickly.

What is the difference between lab data and field data in PageSpeed?

Lab data is a simulated measurement from a standardized computer running your page under controlled network conditions (Google's Lighthouse tool). Field data (also called CrUX data) is real measurements from actual Chrome users who have visited your site over the past 28 days. Field data is what Google actually uses for ranking purposes. Lab data is useful for identifying issues; field data is what matters for Google's assessment.

Do Core Web Vitals affect my website's conversion rate as well as rankings?

Yes. Poor Core Web Vitals - especially high LCP (slow load) and high CLS (visual instability) - directly increase bounce rates and reduce conversion rates. Google's data shows sites meeting Core Web Vitals thresholds experience 24% fewer page abandonments. These are users who would otherwise have bounced before inquiring. Core Web Vitals improvement is simultaneously an SEO and a revenue investment.

The Bottom Line

Core Web Vitals are Google's attempt to measure what your customers already know: some websites feel fast and reliable, and some feel slow and broken. Passing all four metrics is achievable for almost every business website, and the highest-impact fixes - image compression, adding image dimensions, upgrading hosting - are accessible without advanced developer skills. The investment in Core Web Vitals improvement pays back in two ways simultaneously: better Google rankings and higher conversion rates from the traffic you already have.