Core Web Vitals are Google’s three numbers for how a page actually feels to a real visitor: how fast the main content appears, how quickly the page reacts when you tap or click, and how much the layout jumps around while it loads. If you can read those three numbers — LCP, INP, and CLS — and know what “good” looks like for each one, you can understand almost any speed report Google throws at you.
This guide explains core web vitals in plain English: what each metric measures, why Google cares about it, what score to aim for, and the practical fixes that move each number. No jargon degree required.
What Are Core Web Vitals, Exactly?
Core Web Vitals are a small set of metrics Google uses to judge the user experience of a web page. They are part of Google’s broader page experience signals, which means they feed into how your pages rank in search — not as the deciding factor, but as a real one, especially when two pages are otherwise evenly matched.
The key word is core: Google measures dozens of things about a page, but these three are the ones it considers essential, because they map directly to what a visitor notices:
- Loading — does the content show up quickly?
- Interactivity — does the page respond when I touch it?
- Visual stability — does the page stay still once it appears?
Each vital has a name, a unit, and a “good / needs improvement / poor” threshold. Google measures them from real visitors’ browsers (called field data) wherever enough people visit your page, and it also estimates them in lab tests like PageSpeed Insights. The field data is what counts for ranking.
LCP — Largest Contentful Paint (How Fast Does It Load?)
What it measures: how long it takes for the largest visible piece of content — usually the hero image, a big banner, or the main headline block — to appear on screen.
Good: under 2.5 seconds. Needs improvement: 2.5 to 4 seconds. Poor: over 4 seconds.
LCP is the closest thing to “how fast does this page load” in a single number, and it is the vital most site owners struggle with first. I ran a small test recently on a local business site that felt perfectly quick on the owner’s office Wi-Fi: the LCP on a phone was 5.8 seconds, and the culprit was a single 2.4 MB hero photo that had been uploaded straight from a camera. Resizing it to the size it actually displays at and compressing it cut the LCP to 2.1 seconds in one move.
What usually hurts LCP:
- Oversized hero images or background videos
- Slow server response times (the page can’t paint what it hasn’t received)
- Render-blocking CSS and JavaScript in the head
- Web fonts that delay the first text
Fixes that move it most: compress and properly size images above the fold, use a fast host or caching, defer non-critical scripts, and preload the hero image so the browser fetches it first.
INP — Interaction to Next Paint (How Fast Does It React?)
What it measures: how long the page takes to respond after a visitor taps a button, clicks a link, or types in a field — measured from the interaction until the next visible update on screen. Google looks at the worst-ish interactions across a visit, not just the best one.
Good: under 200 milliseconds. Needs improvement: 200 to 500 milliseconds. Poor: over 500 milliseconds.
INP replaced an older metric called FID in March 2024, because FID only measured the delay before the browser started handling a tap, not how long the visitor waited to see anything happen. INP measures the full wait, which is what people actually feel.
A slow INP feels like a broken page. You tap “Add to cart” and nothing happens for half a second, so you tap again — and then it fires twice. The usual cause is JavaScript: long tasks that hog the browser’s main thread, heavy third-party scripts (chat widgets, trackers, social embeds), and event handlers that do too much work at once.
What usually hurts INP:
- Heavy JavaScript bundles that keep the main thread busy
- Third-party scripts loading early and competing for attention
- Long tasks — single chunks of work that block the browser for more than 50 milliseconds
Fixes that move it most: break up long JavaScript tasks, defer or remove third-party scripts that don’t help in the first seconds, and avoid loading interactive widgets until the visitor actually needs them.
CLS — Cumulative Layout Shift (Does the Page Jump Around?)
What it measures: how much visible content moves unexpectedly while the page loads — text sliding down when an ad or image finally arrives, a button jumping just as you are about to tap it. CLS is a score, not a time: it combines how much of the screen moved and how far it moved.
Good: below 0.1. Needs improvement: 0.1 to 0.25. Poor: over 0.25.
CLS is the most annoying vital to experience and the easiest to fix once you see it. The classic cause is an image or ad slot with no reserved space: the browser renders the text first, then the image arrives and shoves everything down. I once watched a visitor on a slow connection tap “Buy now” three times because a late-loading banner kept pushing the button out from under their thumb. Every one of those taps landed on the wrong thing.
What usually hurts CLS:
- Images, videos, and embeds without width and height set
- Ads or banners injected into the page after it renders
- Web fonts that swap in and reflow the text
- Content inserted above existing content (pop-ups, notification bars)
Fixes that move it most: always set width and height on images and videos so the browser reserves the space, reserve a fixed-height slot for ads, and avoid inserting anything above content the visitor is already reading.
How to Check Your Own Core Web Vitals
You don’t need to guess — three free tools will show you your numbers:
- PageSpeed Insights (pagespeed.web.dev) — enter any URL and read the “Core Web Vitals Assessment” at the top. It shows field data from real visitors when available, plus lab scores and a list of fixes ranked by impact.
- Google Search Console — the Core Web Vitals report under the Experience section shows every URL on your site grouped as Good, Needs improvement, or Poor, for mobile and desktop separately. Start here when you want the site-wide picture.
- Chrome DevTools — the Performance panel records a page load and flags layout shifts and long tasks as they happen, which is the fastest way to find the exact element causing a bad CLS or INP score.
Check the mobile numbers first. Google indexes the mobile version of your site, and mobile visitors are the ones on slower connections and smaller screens — the place where bad vitals hurt most.
If you want to see how your layout holds up on different screen sizes while you are at it, try it on your own site with our free responsive preview tool — layout shifts and small-screen problems often travel together, and catching both in one pass saves a second round of fixes.
Do Core Web Vitals Affect Your Google Rankings?
Yes, but with honest limits. Core Web Vitals are one of several page experience signals Google uses in ranking. A page with good vitals will not outrank a far more relevant page just because it loads faster — but when two pages cover the same topic equally well, the one that loads fast, reacts instantly, and stays still has the edge. And the effect goes beyond the ranking signal itself: fast, stable pages keep visitors around, and visitors who stay are the ones who read, click, and come back.
Think of it as table stakes, not a magic trick. Get all three vitals into the green and you have removed a handicap. Leave one in the red and you are competing with a weight on.
Frequently Asked Questions
What are Core Web Vitals in simple terms?
Core Web Vitals are Google’s three measurements of how a page feels to use: LCP measures how fast the main content appears (good under 2.5 seconds), INP measures how quickly the page reacts to taps and clicks (good under 200 milliseconds), and CLS measures how much the layout jumps around while loading (good below 0.1).
What is a good Core Web Vitals score?
Good means an LCP under 2.5 seconds, an INP under 200 milliseconds, and a CLS score below 0.1. Google rates each metric separately as Good, Needs improvement, or Poor, using data from real visitors’ browsers. A page passes the Core Web Vitals assessment only when all three metrics are Good.
How do I check my website’s Core Web Vitals for free?
Enter your URL in PageSpeed Insights (pagespeed.web.dev) for a per-page report with field and lab data, or open the Core Web Vitals report in Google Search Console to see every URL on your site grouped by status. Chrome DevTools’ Performance panel shows layout shifts and long tasks as they happen.
Why did my Core Web Vitals get worse after I changed my theme?
A new theme can change all three metrics at once: heavier images and scripts raise LCP and INP, and a layout that loads ads or banners without reserved space raises CLS. Re-run PageSpeed Insights after any theme change and compare the before-and-after numbers, then fix the worst metric first.