What Is Core Web Vitals?
Core Web Vitals are a set of three metrics Google uses to measure real-world user experience on a web page: Largest Contentful Paint (LCP) for loading speed, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. Each has target thresholds a page should meet to be considered good. They are part of Google's page experience signals and are measured from real Chrome user data. Passing them means a page loads quickly, responds fast to input, and does not jump around as it loads.
- The three metrics
- LCP (loading), INP (responsiveness), CLS (visual stability) (web.dev)
- Good LCP
- 2.5 seconds or less for the main content to load (web.dev)
- Good INP
- 200 milliseconds or less response to interactions (web.dev)
- Good CLS
- A layout shift score of 0.1 or less (web.dev)
- Measured from
- Real Chrome user data (field data) plus lab tools like Lighthouse
What Core Web Vitals measure #
Core Web Vitals are three specific metrics Google uses to quantify how real people experience the speed and stability of a web page, rather than relying on vague impressions of 'fast' or 'slow.' The trio covers loading, interactivity, and visual stability: Largest Contentful Paint measures how quickly the main content appears, Interaction to Next Paint measures how fast the page responds when someone taps or clicks, and Cumulative Layout Shift measures how much the layout jumps around while loading. Each has a clear target that marks the boundary between a good and a poor experience. Together they form part of Google's broader page experience signals, and because they are drawn from real Chrome usage data, they reflect what your actual visitors feel, not just a lab test. Improving them makes a site feel snappier and more trustworthy, which is the whole point of our /services/speed-optimization page, where these three numbers are the scoreboard for real, measurable performance work.
Largest Contentful Paint (LCP): loading #
Largest Contentful Paint measures how long it takes for the largest visible element in the viewport, usually a hero image, heading, or block of text, to finish rendering. It answers the visitor's instinctive question: 'has the main content loaded yet?' Google considers an LCP of 2.5 seconds or less good, up to 4 seconds needs improvement, and over 4 seconds is poor (web.dev). Slow LCP usually comes from a slow server response, large unoptimized images, render-blocking CSS and JavaScript, or slow-loading web fonts.
LCP thresholds (largest element render time):
Good <= 2.5 s
Needs improvement 2.5 s - 4.0 s
Poor > 4.0 sInteraction to Next Paint (INP): responsiveness #
Interaction to Next Paint measures how quickly a page visually responds after a user interacts with it, such as tapping a button, clicking a link, or typing in a field. It captures the delay between the action and the next frame the browser paints, reflecting how sluggish or snappy the page feels in use. INP replaced the older First Input Delay metric in 2024 because it assesses responsiveness across the whole visit rather than just the first interaction (web.dev). Google rates an INP of 200 milliseconds or less as good, 200 to 500 as needing improvement, and over 500 as poor. Poor INP usually stems from heavy JavaScript that ties up the browser's main thread, so that when a user acts, the page cannot respond promptly. Fixing it means trimming and deferring scripts, breaking up long tasks, and reducing third-party code. Because responsiveness strongly shapes how modern, well-built a site feels, it is a core focus of the performance engineering on our /services/speed-optimization page rather than an afterthought.
Cumulative Layout Shift (CLS): visual stability #
Cumulative Layout Shift measures how much the content of a page unexpectedly moves around while it loads. Everyone has experienced it: you go to tap a button, an image or ad finishes loading above it, the whole layout jumps, and you tap the wrong thing. CLS scores that frustration. A score of 0.1 or less is good, up to 0.25 needs improvement, and above 0.25 is poor (web.dev). The usual culprits are images and embeds without defined dimensions, ads or banners injected after load, and web fonts that reflow text when they swap in. The fixes are concrete: always set width and height attributes on images and videos so the browser reserves space, allocate room for ads and embeds in advance, and load fonts in a way that avoids reflow. Because a stable layout is invisible when done right but maddening when done wrong, eliminating unexpected shifts is a standard part of the build quality on our /services/web-design page, where reserving space for every element prevents the jump entirely.
Why Google uses these metrics #
Google introduced Core Web Vitals to put an objective, user-centered number on page experience, which had previously been hard to measure consistently. The metrics matter for two reasons. First, they directly reflect how visitors feel: a fast-loading, responsive, stable page keeps people engaged, while a slow, jumpy one drives them away, hurting conversions and revenue regardless of search. Second, page experience is a ranking signal, so Core Web Vitals are one of the many factors Google weighs when ordering results (Google Search Central). They are not the single biggest factor, and great content on a slower page can still outrank thin content on a fast one, but among comparable pages, better vitals help. The important framing is that improving them benefits your business twice: happier users and a modest search advantage. That dual payoff is why performance work sits alongside content and technical health in a complete SEO program, and why our /services/seo-services page treats Core Web Vitals as part of the technical foundation rather than an isolated tweak.
Field data versus lab data #
There are two ways to measure Core Web Vitals, and understanding the difference prevents confusion. Field data, also called real-user monitoring, comes from actual Chrome users visiting your site under real conditions, collected in the Chrome User Experience Report; this is what Google uses to assess page experience. Lab data comes from tools that simulate a single load in a controlled environment, such as Lighthouse or PageSpeed Insights, useful for diagnosing and debugging but not identical to what real users experience. The two can disagree, because real visitors use varied devices and networks while a lab test uses fixed conditions, and INP in particular can only be measured properly in the field since it depends on real interactions. The practical approach is to use lab tools to find and fix problems, then watch field data to confirm real users benefit. A quick starting point is our /tools/website-grader, which surfaces performance issues in plain language before you dive into the more technical measurement tools.
How to improve your Core Web Vitals #
Improving the three metrics follows a clear playbook. For LCP, speed up the server response, compress and correctly size images, serve modern image formats, use a CDN, and remove render-blocking CSS and JavaScript so the main content appears fast. For INP, reduce and defer JavaScript, break long tasks into smaller pieces, and cut heavy third-party scripts so the main thread stays free to respond to input. For CLS, set explicit dimensions on all images, videos, and embeds, reserve space for ads and dynamic content, and load fonts without causing reflow. Caching, compression, and lazy-loading offscreen images support all three. The work is measurable: you fix a cause, retest, and watch the number improve, then confirm it in field data over the following weeks. Because these optimizations touch code, images, hosting, and fonts together, they reward a coordinated effort rather than one-off tweaks, which is exactly how our /services/speed-optimization page approaches a site, targeting the specific metric that is failing rather than guessing.
Core Web Vitals on mobile devices #
Core Web Vitals matter most on mobile, because that is where conditions are hardest and where most searches now happen. Phones have less processing power than desktops, and mobile networks are often slower and less stable, so a page that scores well on a fast office connection can still fail its vitals for a real visitor on a phone. Google largely evaluates page experience using mobile data, so mobile performance is what counts for both users and ranking. Heavy JavaScript hurts INP more on modest phone processors, large images inflate LCP over cellular connections, and layout shifts are especially jarring on small screens where a misplaced tap is easy. The practical takeaway is to test and optimize for a mid-range phone on a typical mobile network, not just your own fast device. Designing layouts that stay stable and responsive on small screens is part of the mobile-first approach on our /services/ui-ux-design page, ensuring the experience your metrics measure is the one your largest audience actually has every day.
Setting realistic performance goals #
The goal is for the majority of your real visitors to have a good experience, which Google assesses by whether the 75th percentile of page loads meets each 'good' threshold. In plain terms, aim for at least three-quarters of visits to hit LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. Perfection is not required, and chasing a flawless lab score while ignoring real-user field data is a common mistake, since only field data reflects what your audience actually feels. Prioritize the metric that is failing most and affects the most visitors first. Remember the broader point: these numbers are a proxy for a fast, stable, responsive site, so the real win is a better experience that converts more visitors, not the score itself. If you are unsure where your site stands or which metric is dragging it down, a /free-website-audit will pinpoint the specific vitals to fix and the causes behind them.
FAQ
What are the three Core Web Vitals?
They are Largest Contentful Paint (LCP), which measures how fast the main content loads; Interaction to Next Paint (INP), which measures how quickly the page responds to taps and clicks; and Cumulative Layout Shift (CLS), which measures how much the layout moves unexpectedly while loading. Together they quantify a page's loading, responsiveness, and visual stability.
What are good Core Web Vitals scores?
A good LCP is 2.5 seconds or less, a good INP is 200 milliseconds or less, and a good CLS is 0.1 or less. Google assesses these at the 75th percentile of real visits, so the aim is for at least three-quarters of your visitors to experience these good thresholds on their devices.
Do Core Web Vitals affect SEO rankings?
Yes, but modestly. Core Web Vitals are part of Google's page experience signals and act as one ranking factor among many. They are not the biggest factor, and strong content can outrank a faster but weaker page. Among comparable pages, though, better vitals help, and they also improve conversions regardless of search.
What replaced First Input Delay in Core Web Vitals?
Interaction to Next Paint (INP) replaced First Input Delay (FID) as the responsiveness metric in March 2024. INP is a better measure because it assesses how quickly a page responds across all interactions during a visit, not just the very first one, giving a more complete picture of how snappy the page feels in real use.
How do I check my Core Web Vitals?
Use Google's PageSpeed Insights or Search Console for field data from real Chrome users, and Lighthouse for lab diagnostics. Field data reflects actual visitor experience and is what Google uses, while lab tools help you find and fix specific problems. A simpler website grader can also surface the issues in plain language to start.
How can I improve a poor Core Web Vitals score?
Target the failing metric: for LCP, optimize images, speed up the server, and remove render-blocking code; for INP, reduce and defer JavaScript; for CLS, set image dimensions and reserve space for ads and embeds. Caching, compression, a CDN, and lazy-loading help all three. Fix, retest, then confirm improvement in real-user field data.
How Local Web Advisor checks this for you
Is your own website getting speed & core web vitals right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for speed & core web vitals and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?