Core Web Vitals are three measurements of how a page feels to a real visitor: how fast the main content appears, how quickly the page responds when someone taps or clicks, and whether the layout stays still while it loads.
This guide explains what are Core Web Vitals, what a good score looks like, and where to check yours.
They matter because visitors judge a site’s user experience in seconds, and a slow or jumpy page can lose people before your message lands. Google also uses them as part of how it judges page experience in search.
It is written for site owners and marketers, not developers. You will learn what each metric means in plain words, see one everyday example of each, and finish with a short list of fixes to hand to whoever builds your site.
Core Web Vitals sit inside that work. They are the part of technical SEO that measures how a page performs for people, not only whether a search engine can read it.
What are Core Web Vitals? Three measures of loading, responsiveness and visual stability
According to web.dev, Core Web Vitals are the subset of Web Vitals that apply to all web pages. There are three Core Web Vitals metrics, and each one covers a different part of the visit.
Largest Contentful Paint (LCP) measures loading. Interaction to Next Paint (INP) measures responsiveness. Cumulative Layout Shift (CLS) measures visual stability. Google calls them real-world user experience measures, which means they come from actual visits, not from a lab test.
The good thresholds at a glance
web.dev publishes the targets, and they are the same on every site. A page is judged at the 75th percentile of page loads, segmented across mobile and desktop. That means three out of four visits should meet each target.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint | Loading speed of the main content | 2.5 seconds or less | More than 4.0 seconds |
| Interaction to Next Paint | Responsiveness to taps, clicks and key presses | 200 milliseconds or less | More than 500 milliseconds |
| Cumulative Layout Shift | Visual stability while the page loads | 0.1 or less | More than 0.25 |
Values between good and poor fall in the “needs improvement” range. A page passes the Core Web Vitals assessment only when it meets the good target on all three metrics at the 75th percentile.
What changed from First Input Delay to INP
You may still see First Input Delay (FID) in older guides. FID only measured the input delay of the first interaction on a page. web.dev describes INP as the successor metric that observes all interactions, and its launch post says INP became a Core Web Vital in March 2024.
If a guide tells you the three metrics are LCP, FID and CLS, it is out of date.
Largest Contentful Paint is how long the main thing takes to show up
LCP reports the render time of the largest image, text block or video visible in the viewport. On most pages that is the hero image or the main headline.
It is the moment a visitor feels the page has arrived. Unlike a single page load time, LCP tracks when the main content appears, which is what users perceive as the page being ready.
Web.dev sets a good LCP at 2.5 seconds or less. The clock includes connection setup, redirects and the wait for the first byte from your web server, not only the image download.
An example of LCP
Imagine a safari lodge homepage with a full-width photo and a headline over it. The photo is 4 MB, so on a phone the headline appears quickly and the photo arrives several seconds later.
The photo is the largest element, so the page’s LCP is the moment the photo finishes drawing. This is an illustration, not a measured result.
What usually fixes a slow LCP
web.dev’s LCP optimization guide splits the time into four parts: time to first byte, resource load delay, resource load duration and element render delay. It says the vast majority of the time should be spent loading the HTML document and the main image.
For a non-developer, that translates into a handful of requests. Ask your developer to compress the hero image, to never use lazy loading on it, and to avoid long chains of redirects. web.dev says never to lazy-load your LCP image, because it always adds unnecessary delay.
One more lever is fetch priority. In a test of Google Flights, web.dev reports that setting a high priority on the main image improved LCP from 2.6 seconds to 1.9 seconds.
That is Google’s own test on its own page, so treat it as a sign of what is possible, not a promise for your site.
Interaction to Next Paint is how quickly the page reacts when someone uses it
INP assesses a page’s overall responsiveness by observing the latency of every click, tap and keyboard interaction during a visit. Hovering, zooming and scrolling are not counted. The page reports a single value that reflects the slow end of those interactions.
Per web.dev, an INP at or below 200 milliseconds means good responsiveness, and above 500 milliseconds means poor responsiveness. Because it covers every user interaction, a page can load fast and still fail INP. A page that answers user input without delay feels like a seamless user experience, and one that lags feels broken.
An example of INP
Picture a quote form with a “Send” button. A visitor taps it and nothing visibly happens for a second, because the page is busy running scripts for a chat widget and an analytics tag.
The visitor taps again. That gap between the tap and the next frame is what INP measures. Again, this is an illustration.
What usually fixes a slow INP
web.dev’s INP optimization guide breaks each interaction into input delay, processing duration and presentation delay. Its general advice on event callbacks is to do as little work as possible in them, and to yield to the main thread so long tasks do not block the page.
In plain terms, the usual causes are too many third party tools, heavy scripts and plugins. Removing a tag you do not use is often the fastest fix. For marketing teams, that means auditing the chat widgets, pop-ups and trackers on the site.
Cumulative Layout Shift is whether the page stays still while you read it
CLS measures the largest burst of layout shifts, which are unexpected movements of content on screen. Shifts are grouped into bursts when each comes less than a second after the last, with a maximum window of five seconds.
web.dev defines good CLS as 0.1 or less and poor as greater than 0.25. A shift that follows a tap does not count as unexpected, so a menu that opens when you press it is fine.
An example of CLS
You are reading an article on your phone and are about to tap a link. An advert loads above it and the text jumps down, so you tap the wrong thing. That jump is a layout shift. Illustration only, but you have likely felt it.
What usually fixes a high CLS
web.dev’s CLS optimization guide lists four common fixes. Always include width and height attributes on images and video. Reserve space for ads and embeds with a minimum height. Load critical web fonts early with a matching fallback font. Animate with transform, not with top and left.
The common causes are images with unknown dimensions, web fonts that render differently from the fallback, content added late, and third party widgets that resize themselves.
How to ensure visual stability on the entire page
The goal is a page layout that stays visually stable from the first paint to the last. To ensure visual stability, the browser needs to know how much room each of the page elements will take before they load.
Width and height attributes, or a CSS aspect ratio box, let it reserve that space, and that prevents unexpected layout shifts.
Why Google Core Web Vitals matter for your site’s user experience
Every visit is a small test of patience. A visitor who waits too long, taps and gets no response, or loses their place when the page jumps has a poor experience, and some will leave.
Good Core Web Vitals do not guarantee a sale, but they support user satisfaction, and poor ones make every other part of your marketing work harder.
These metrics describe user behavior as it happens on real pages: what visitors wait for, what they tap, and what moves under their thumb. That is why the data comes from actual users, and why a perfect lab score is not the finish line.
Are Core Web Vitals important for search rankings?
Google says it highly recommends that site owners achieve good Core Web Vitals for success with Search. It adds that, along with other page experience aspects, this aligns with what its core ranking systems seek to reward.
Many articles call them a direct ranking factor, but Google’s own wording is more careful. Notice what Google does not say. It does not give the metrics a fixed weight in search rankings, and it does not say they replace relevant content.
Treat them as page experience signals that sit beside relevance when Google is ordering ranking pages, and think of them as a floor: a page with excellent content can still lose a visitor to a slow load or a jumping layout.
That is why we treat them as part of the base layer in our guide to being found in search and AI answers, and why they appear in a site that is built to be found from the first day.
Page experience is also something to protect when you launch a new website without losing search traffic.
Page speed is related, but it is not the same thing
People often use “page speed” and Core Web Vitals as if they meant one thing. Page speed is a loose idea about how fast a page loads.
The three metrics are specific: one for loading, one for responsiveness and one for visual stability. A site’s performance can be quick to load and still fail on INP or CLS. Mobile friendliness is a different check again: a page can fit a small screen and still be slow to respond.
A quick map from symptom to metric
| What a visitor says | Metric to check | Likely owner |
|---|---|---|
| “The page took forever to show up” | LCP | Developer or hosting provider |
| “I tapped and nothing happened” | INP | Developer, plus whoever adds third party tools |
| “Everything jumped when I tried to click” | CLS | Developer and the team that adds adverts and embeds |
Passing on desktop devices does not mean passing on a phone, because the report separates the two. On mobile devices these problems show up first, because phones often have slower processors and less stable connections than a desktop. Always read the mobile report first.
Check your own scores with free Google tools
You do not need paid software. Three free Google tools and one add-on cover the question of how to measure Core Web Vitals on a small site. Between them they give you Core Web Vitals data from real visits and performance data from controlled tests.
- Google Search Console has a Core Web Vitals report that groups your indexed URLs as Poor, Need improvement or Good, split by mobile and desktop. It groups similar web pages together, so you can see which page types need work.
- PageSpeed Insights shows both field data and lab data for one URL and says whether the page passes the assessment.
- The Chrome User Experience Report, known as CrUX, is the public dataset of real-world Chrome visits behind both tools.
- Real user monitoring tools record the same metrics on your own visitors, which helps once your traffic is large.
Field data and lab data are not the same thing
Field data is actual user data, sometimes called real world usage data, and it comes from real visitors. Lab data comes from one test on one device and one network. web.dev explains that lab data and field data measure very different things, which is why a lab score can look fine while real users struggle.
Use field data to judge whether you pass, and lab data to debug a fix. Google’s PageSpeed Insights documentation says the same: lab data is useful for debugging, and field data reflects actual users.
Why Search Console may say “No data available”
The Core Web Vitals report takes its data from CrUX, and only indexed URLs can appear in it.
Google’s report help page says “No data available” can mean a property is new in Search Console or that there is not enough data for the selected device type. A small site with little traffic may see this for a while. Nothing is broken.
How to improve Core Web Vitals without a rebuild
You can improve Core Web Vitals on most small sites with a short list of changes. Optimizing images is a common LCP fix. Removing unused scripts helps INP.
Setting image dimensions and reserving space for embeds addresses the usual CLS causes. A content delivery network can also serve files from a location closer to the visitor, which shortens the wait for the first byte.
When one of the three is poor, treat it as a Core Web Vitals performance problem with a specific owner, not a vague “the site is slow”. If you run a site audit, add these three checks to it.
Core Web Vitals are a topic for web development teams, but the checks are simple enough for a marketer to run and track. Our technical SEO term in the Brand Library shows where they fit among the other checks.
Fix in this order when your scores are poor
Not every site needs all of this. Start with the metric that is failing, and with the page types that bring in the most visits.
- Open the Search Console report and note which metric is poor on mobile.
- For poor LCP, fix the hero image: size, format, no lazy loading, no redirect chain.
- For poor INP, remove unused scripts, chat widgets and tags before anything else.
- For poor CLS, add image dimensions and reserve space for adverts and embeds.
- Check again after a few weeks, because field data updates over time.
Poor Core Web Vitals are rarely fixed in one afternoon. Treat the first change as a baseline, and read your site’s Core Web Vitals scores again once new field data has arrived.
If you rebuild or redesign, put the three targets in the brief so they are met at launch and not repaired afterward. The local SEO checklist is a good companion if your visitors find you on a phone, since mobile is where these problems show first.
Keep going with the full playbook
Core Web Vitals are one layer of being found. The ebook Be Where They Look walks through search and distribution for brands that want the right visitors, not just more of them. And every Wednesday the Ground Truth newsletter sends one practical idea on search and brand growth.
FAQ
What are the Core Web Vitals?
They are the three core web vital metrics: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. They come from real visits, and web.dev sets the good targets at 2.5 seconds, 200 milliseconds and 0.1.
What is a good LCP score?
web.dev says a good LCP is 2.5 seconds or less, and poor values are greater than 4.0 seconds. It is measured at the 75th percentile of page loads, so three out of four visits should meet it.
How do I pass the Core Web Vitals assessment?
Meet the good threshold for all three metrics at the 75th percentile. Google’s PageSpeed Insights documentation says the assessment passes when the 75th percentiles of INP, LCP and CLS are all good. Fix the failing metric first, then recheck.
How do I check Core Web Vitals for my site?
Open the Core Web Vitals report in Google Search Console for your indexed pages, and run a single page through PageSpeed Insights. The first shows field data across your site. The second shows field data and lab data for one URL.
Do Core Web Vitals affect search rankings?
Google recommends good Core Web Vitals for success with Search and says they align with what its core ranking systems seek to reward. It does not publish a weight, so treat them as one part of page experience alongside relevant content.