Core Web Vitals are the three metrics Google uses to measure real user experience on a web page: LCP for loading, INP for responsiveness and CLS for visual stability. A page counts as good when, at the 75th percentile of visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less.
This article covers what each metric measures, how to read the thresholds, the difference between lab and field data and how to measure your site step by step with PageSpeed Insights and Search Console. In website development, these values are not details to fix after launch but targets to track from the first day of design.
Why do Core Web Vitals matter?
Speed is the first relationship a user has with a site. A page that loads late, ignores a tap or shifts while you read loses trust, however good its content is. Core Web Vitals put that experience on measurable values instead of guesswork.
Google counts Core Web Vitals among the page experience signals its search systems consider. They do not replace good content and do not decide rankings on their own, but because they shape user experience directly, they make a difference in both visibility and conversion. We cover the other parts of visibility in search and AI answer engines in SEO and SEM in the age of AI search.
What do LCP, INP and CLS measure?
Each metric looks at a different moment of the user experience:
- LCP (Largest Contentful Paint): The time from when the page starts loading until the largest image, video or text block in the viewport is rendered. It stands for the moment a user feels the page has loaded. Good is 2.5 seconds or less; above 4 seconds is poor.
- INP (Interaction to Next Paint): How long the page takes to respond visually after the clicks, taps and key presses made during a visit. The longest interaction is reported, with outliers ignored. Good is 200 milliseconds or less; above 500 milliseconds is poor. INP replaced FID (First Input Delay) in March 2024.
- CLS (Cumulative Layout Shift): A unitless score for how much content moves unexpectedly while the page is in use. The line you are reading jumping down because an image loaded late is a typical layout shift. Good is 0.1 or less; above 0.25 is poor.
Alongside these three, supporting metrics such as TTFB (Time to First Byte) and FCP (First Contentful Paint) exist. They are not part of Core Web Vitals, but they help find the source of LCP problems in particular.
How do you read the thresholds, and what is the 75th percentile?
Google uses three bands for each metric: good, needs improvement and poor. The assessment looks not at a single visit but at the distribution of real visits, and it uses the 75th percentile of that distribution.
The 75th percentile is the point at which 75 percent of visits are at that value or better. If a page's LCP at the 75th percentile is 2.3 seconds, at least three out of four visits saw the main content within 2.3 seconds. This approach accounts for users on slow devices and connections without letting a handful of extreme visits distort the result.
Two more details matter:
- Mobile and desktop are assessed separately. A page that is fast on desktop can fall short on mobile.
- To pass the Core Web Vitals assessment, all three metrics must be in the good band. One poor metric pulls the result down, however good the other two are.
What is the difference between lab data and field data?
Lab data comes from testing a page in a controlled environment that simulates a specific device and network. Lighthouse is a tool of this kind. Because results are repeatable, lab data is ideal for finding problems and seeing the effect of a change right away.
Field data is collected from the devices of people who actually visit your site. Google's Chrome User Experience Report (CrUX) gathers it from Chrome users who have opted in, over a rolling 28-day window. The Core Web Vitals assessment is based on field data.
Knowing the difference keeps you from drawing the wrong conclusions:
- A lab test has no real user interaction, so it cannot measure INP directly; a proxy such as Total Blocking Time (TBT) is used instead.
- The Lighthouse performance score is a lab score from 0 to 100 and does not replace the Core Web Vitals assessment.
- Low-traffic pages may not have enough field data in CrUX. In that case, lab tests and real user monitoring (RUM) added to your site guide the work.
For example, the website we built for Kemerköy Sitesi with WebP images, Brotli compression and page caching scored 94 for mobile performance and 100 for desktop performance in an October 2026 Lighthouse lab test. A result like that shows the page is technically sound; field data confirms the real user experience.
How do you measure with PageSpeed Insights and Search Console?
Two free Google tools give most sites a solid starting point:
- Measure a single page with PageSpeed Insights. Enter the page URL. The top section shows field data from real users over the last 28 days, when there is enough of it, along with the Core Web Vitals assessment; the lower section holds the Lighthouse lab test and suggestions. Review mobile and desktop results separately.
- Monitor the whole site with Search Console. The Core Web Vitals report groups similar pages and classifies them as good, needs improvement or poor. A group's status is set by its weakest metric. This report shows which template is causing trouble.
- Validate the fix. Once you have fixed an issue, start validation in Search Console. Because field data relies on a 28-day window, improvements take time to show up in the reports.
- Use Chrome DevTools during development. The Performance and Lighthouse panels let you see the effect of a change before it goes live.
How do you improve each metric?
Most problems have known causes and known fixes:
- For LCP: Serve the main image in a modern format such as WebP or AVIF at the right size, do not lazy-load it and give it high priority. Cut server response time with caching and compression, and reduce the CSS and JavaScript that block rendering.
- For INP: Break up JavaScript tasks that keep the browser's main thread busy, remove unused code and review third-party scripts such as chat widgets, ads and tracking tags. Give users immediate visual feedback after an interaction.
- For CLS: Set width and height on images and videos, reserve space for ads and embeds, avoid inserting elements above existing content and keep web fonts from shifting text as they load.
Making changes one at a time and checking each in a lab test is the most reliable way to learn which step worked. You track the lasting result in field data.
Scores come from the lab; experience happens in the field.
Frequently asked questions
My Lighthouse score is high, so why does the Core Web Vitals assessment fail?
Lighthouse simulates one device and network condition, while the assessment relies on real user data. Slower phones, weak connections and real interactions can expose problems that never appear in the lab.
How much do Core Web Vitals affect rankings?
Google uses them among its page experience signals, but relevance to the query and content quality weigh more. Treat speed not as a shortcut that replaces content but as the experience good content deserves.
PageSpeed Insights shows no field data. What should I do?
Your page or site may not yet have enough traffic to appear in CrUX. Work from lab tests in the meantime and set up your own real user monitoring with a tool such as Google's open-source web-vitals library.
Do the Core Web Vitals metrics change over time?
Yes. Google can update the set to better reflect user experience; INP replacing FID in 2024 is one example. Follow Google's official documentation for the current thresholds.
Why are my mobile results lower than desktop?
Mobile devices usually have slower processors and less stable connections, and the PageSpeed Insights mobile lab test simulates those conditions. If most of your visitors come from phones, prioritizing mobile results matters most.
Where to start?
Measure a few of your most visited pages on mobile in PageSpeed Insights and check the Core Web Vitals report in Search Console. If a group is poor or needs improvement, pick the biggest problem in that template, fix it and watch the field data change.
If you want to measure your site's speed together and build an improvement plan, get in touch.