What are Core Web Vitals?
Core Web Vitals are Google's way of measuring how fast and stable a web page feels to the person visiting it. The metrics affect both how visitors experience the site and how it shows up in search. This guide goes through the three metrics, the difference between lab tests and real-world data, and what is actually worth prioritising.
By Simon Torngren · Partner and COO· Published · Updated Our view
Core Web Vitals measure the user's patience, not a technical score. A green gauge is worth something only when it means fewer drop-offs and more completed actions. Optimise for what the visitor experiences, not for a perfect number in a lab test.
What Core Web Vitals are.
Core Web Vitals are a set of metrics from Google that describe how a web page is experienced by the person visiting it: how quickly it loads, how promptly it responds to interaction and how stable it is while it builds up on the screen. They are part of what Google calls page experience, meaning signals for the experience of a page.
The point of the metrics is that they start from the user, not from the technology. A site can be technically well built and still feel slow, or have a fast server but jump around so much that it is annoying to use. Core Web Vitals try to capture exactly that perceived quality, in three concrete numbers.
web.dev on Core Web Vitals↗ is Google's own documentation of the metrics. The important thing to take away is that the three numbers are not an end in themselves: they are a way of putting figures on whether the site feels fast and reliable to a real visitor.
The three metrics.
Core Web Vitals consist of three metrics, one each for loading, response time and stability. Each has a threshold for what Google counts as good:
- 01LCP, Largest Contentful Paint. Measures how long it takes before the page's largest content (often an image or heading) appears. Good is under 2.5 seconds. It answers the question: how quickly does the visitor see that something has loaded?
- 02INP, Interaction to Next Paint. Measures how quickly the page reacts when someone clicks, taps or types. Good is under 200 milliseconds. It replaced the older FID metric during 2024 and answers: does the page feel responsive or sluggish?
- 03CLS, Cumulative Layout Shift. Measures how much the content jumps around while the page loads, for example when an image pushes the text down. Good is under 0.1. It answers: does the page stay still, or does the button move just as I am about to tap it?
All three need to be green at the same time for a page to count as passing. A good LCP does not help if the layout jumps so much that the visitor clicks the wrong thing. The metrics hang together, because they describe the same thing from three angles: does the page feel fast and reliable to use?
Field data versus lab test.
The same page can get different results depending on how it is measured, and the difference decides what the number is worth. There are two kinds of data:
- Field data is measurements from real visitors, on their own devices and networks. Google collects it through Chrome, and it is the data that actually affects how the page is judged. It reflects reality, including old phones and weak connections.
- Lab data is a simulated test in a controlled environment, for example in the Lighthouse tool. It is excellent for troubleshooting, because it gives the same result every time and points to what is slow. But it is not reality.
This is where the most common trap lies: a page can show 100 out of 100 in a lab test and still have weak Core Web Vitals for real visitors, or the other way around. Chasing a perfect lab score is optimising for the wrong target. Google's documentation on page experience↗ starts from the field data, and so should you: measure on your actual visitors.
What is worth prioritising.
Most performance problems sit in a handful of places, and it is rarely the server that is the culprit. The gains usually come from here:
- Images. Unsized and uncompressed images are the most common cause of slow LCP and a jumping layout. The right format, the right size and stated dimensions solve a large part.
- Third-party scripts. Chat bubbles, analytics, ads and embeds often run first and block the page. Fewer and later-loaded scripts give a faster response time, meaning better INP.
- Fonts. Custom typefaces that load late make text jump in or change appearance halfway through. Loading them smartly removes both flicker and layout shift.
- Reserved space. Setting aside room in advance for images, ads and embeds stops the page from jumping, meaning it lowers CLS, when they appear.
MDN's performance guide↗ is worth digging into for the technical side. But the prioritising is a business question before it is a technical one: fix what shows for the visitor and affects the business first, not what happens to lower a lab score by a few points.
Ranking and business.
Core Web Vitals are a ranking factor in Google, but one of many and rarely the deciding one. A slow page with the best content usually ranks ahead of a lightning-fast one with thin content. Speed is a tiebreaker that helps when everything else is even, not a shortcut past good content.
The real gain lies closer to the business than to the search result. A page that loads fast and stays still loses fewer visitors before they have even seen the content, and makes it easier to complete a purchase or fill in a form. That is where performance work pays off, in drop-offs and completions, not in a gauge.
So speed is decision support, not status: a green gauge is worth something only when it shows up in the business. If you want to know where your site loses visitors to slowness and what is worth fixing, see how Memorise works with web, or read about how performance connects to technical SEO.
Want to know what makes your site slow?
Send us your web address, and we will look at your Core Web Vitals with real visitor data: what is dragging down LCP, INP and CLS, and which fixes are actually worth the time. You get a concrete priority list, not a lab score to frame.
Write to us →Common questions about Core Web Vitals
What are Core Web Vitals?
Core Web Vitals are three metrics from Google that describe how fast and stable a web page feels to the visitor: LCP (how quickly the main content appears), INP (how quickly the page responds to clicks) and CLS (how much the layout jumps). They are part of Google's page experience signals.
What are good values for LCP, INP and CLS?
Google counts LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1 as good. All three should be green at the same time. The values are measured on real visitors, so the result is affected by everything from your images and scripts to the visitor's device and connection.
Do Core Web Vitals affect my ranking in Google?
Yes, but as one of many factors and rarely the decisive one. Good content weighs more than speed. Core Web Vitals mostly work as a tiebreaker between pages that are otherwise equal. The bigger gain lies in fast, stable pages losing fewer visitors, which benefits both business and search indirectly.
What is the difference between Lighthouse and field data?
Lighthouse is a lab test in a controlled environment, good for troubleshooting because it gives the same result every time. Field data is measurements from real visitors, and it is the one Google uses to judge the page. A page can get full marks in Lighthouse and still have weak Core Web Vitals in the field. Trust the field data.
Is a fast host enough for good Core Web Vitals?
No, a fast server helps but is rarely the whole answer. Most problems sit in the page itself: large images, heavy third-party scripts, fonts that load late and layout that jumps. A fast server that delivers a heavy page still gives weak values.