What Are Core Web Vitals? A Simple Guide for Business Owners
Core Web Vitals measure loading, responsiveness and visual stability. Here is what the metrics mean, what they do not prove and how to act on them.
Part of our guide: The Complete Guide to Website Speed for Business Owners
Core Web Vitals are three Google-defined metrics for important parts of a visitor’s page experience: loading, responsiveness and visual stability. They are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. They are useful evidence, but they do not measure the quality of your offer, whether a form works or whether a page deserves to rank.
For a good assessment, LCP should be 2.5 seconds or less, INP 200 milliseconds or less and CLS 0.1 or less at the 75th percentile of visits. The percentile requirement means a few fast visits cannot hide poor experiences for many other visitors.
The three Core Web Vitals at a glance
LCP asks when the page’s main visible content appears. INP asks how promptly the page responds after a visitor interacts. CLS asks how much visible content moves unexpectedly.
Together they reveal different types of friction. A page may appear quickly but respond slowly, or feel fast but jump while someone tries to tap a button. Passing one metric does not compensate for failing another.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.
Largest Contentful Paint: loading
LCP records when the largest eligible image or text block in the viewport finishes rendering. On a business homepage this is often a hero image, heading or prominent content panel. Google’s LCP guidance defines 2.5 seconds or less as good and more than 4 seconds as poor.
A slow LCP can begin before the browser renders anything. The server may respond slowly, the main resource may be discovered late, or a large image and blocking stylesheet may take too long to arrive. The element can differ between mobile and desktop because the viewport and layout differ.
Useful fixes include improving server response, ensuring the main image is discoverable in the initial HTML, serving an appropriately sized asset and avoiding lazy loading the primary above-the-fold image. Measure the actual element before applying generic advice.
Interaction to Next Paint: responsiveness
INP observes the latency of clicks, taps and keyboard interactions throughout a page visit, then reports a representative high value. A good INP is 200 milliseconds or less; more than 500 milliseconds is poor. The official INP guide explains the metric and its thresholds.
Long JavaScript tasks are a common cause. The browser may be processing code when a visitor opens a menu, selects an option or types into a widget. The tap happened, but the next visual response arrived late.
Reduce unnecessary client-side code, break up long work and avoid rerendering more of the page than needed. Test real interactions, because a content page with almost no interaction may provide less diagnostic information than a booking tool or calculator.
Cumulative Layout Shift: stability
CLS adds up unexpected layout movement during the page’s life. A good score is 0.1 or less and more than 0.25 is poor. Google’s CLS guidance describes how shifts are measured.
Common causes include images without dimensions, adverts or embeds without reserved space, web fonts that substantially change text size, and banners inserted above existing content. Movement following a visitor’s deliberate action may be treated differently, but the interface should still remain understandable.
Reserve space for media and dynamic components. Use stable font loading and avoid adding content above the reader without warning. The business impact is practical: shifting controls can cause mistaken clicks and make the site feel unreliable.
Why the 75th percentile matters
Core Web Vitals use the 75th percentile to judge whether most visits receive a good experience. If a metric is good at that percentile, at least three quarters of the measured visits meet the threshold.
An average can hide a significant group with poor performance. The percentile approach encourages teams to consider slower devices and networks rather than optimising only for office laptops.
It does not mean the remaining quarter should be ignored, or that every visit above the threshold is unusable. Segment by device and page type where your tools allow, then investigate persistent patterns.
Field data and lab data are not interchangeable
Field data records eligible real-user experiences. PageSpeed Insights can show Chrome User Experience Report data covering a rolling 28-day period. It may report a specific URL or the whole origin depending on the available sample.
Lab data comes from a controlled Lighthouse simulation. It gives repeatable diagnostics and can be run before launch. It does not capture every visitor, and Lighthouse uses Total Blocking Time as a laboratory proxy rather than directly measuring field INP.
The official Web Vitals tools guide explains which tools can measure each metric. Use field data to understand reported experience and lab data to debug likely causes.
Why PageSpeed can show different answers
The field panel summarises previous real visits while the laboratory section models a new visit now. They have different devices, connections, time periods and measurement methods. A page can therefore pass its field assessment while one lab run looks weak, or the reverse.
Check whether you are viewing URL-level or origin-level data. Repeat lab tests. Note recent releases that may not yet be fully represented in the rolling field period.
Our guide to testing website speed for free provides a repeatable process, while what makes a good PageSpeed score explains the separate Lighthouse score.
Do Core Web Vitals affect Google rankings?
Google says Core Web Vitals are used by its ranking systems, but good results do not guarantee top rankings. Search systems consider many signals, and a relevant, useful page can still outrank a faster but less helpful one.
Improve the metrics because they represent meaningful aspects of customer experience. Treat search benefit as one part of the case, not a guaranteed return. Read does website speed affect Google rankings? for a fuller explanation.
What Core Web Vitals do not measure
They do not tell you whether:
- the visitor understands the service;
- content is accurate and persuasive;
- navigation labels make sense;
- a form delivers to the right inbox;
- the page meets accessibility requirements;
- the business is trustworthy;
- analytics and consent are configured correctly;
- the page is indexed or ranks for a useful query.
A technically fast website can still fail its purpose. Include task completion, accessibility, enquiry quality and content review in the wider evaluation.
Diagnose individual pages
Templates create shared patterns, but pages contain different images, embeds and content. Test the homepage, service pages, articles and conversion journeys separately.
Field data may aggregate at origin level when a URL lacks sufficient samples. That view is useful for a general trend but cannot prove that a specific booking page is healthy. Pair it with lab tests and real-device checks on the page itself.
Set a sensible order of work
Start with severe problems on commercially important pages. If the main service page takes a long time to reveal its heading, address LCP before polishing a minor shift far below the fold. If a booking widget freezes after every selection, its responsiveness may be the priority.
Fix functionality and accessibility regressions immediately. Then tackle repeatable bottlenecks, retest under comparable conditions and monitor field evidence over time. Do not ship several unrelated changes at once if you need to learn which worked.
Discuss metrics with a developer or agency
Ask them to identify:
- the URLs and devices affected;
- whether the evidence is field or laboratory data;
- the element or work causing the metric;
- the proposed change and trade-offs;
- how success will be retested;
- whether the change affects accessibility or functionality;
- how future regressions will be noticed.
Be cautious of promises to maintain a perfect score indefinitely. Results change with content, third-party services, test conditions and browsers. Ask the supplier to commit to a testing process and agreed thresholds.
Improve LCP without erasing the design
Optimise the most important visual rather than removing all imagery. Serve the right dimensions and format, give the browser an appropriate responsive source, and simplify layered effects that delay rendering. A well-chosen photograph can remain part of the brand while becoming substantially lighter.
Reduce blocking styles and fonts thoughtfully. A restrained set of font files often preserves the visual character better than substituting a completely different typeface.
See how to improve speed without losing the design for a design-led process.
Improve INP around real tasks
List the interactions customers actually use: navigation, filters, forms, calendars, accordions and checkout controls. Record which response feels delayed and inspect the main-thread work during it.
Remove unused scripts, delay non-essential third-party code and divide long processing into smaller tasks. Server-rendered or static content can reduce the amount of JavaScript required for content-led pages, but technology alone is not a guarantee.
Improve CLS with stable components
Set width and height or an aspect ratio for images and video. Reserve an expected area for embeds, consent messages and advertisements. Avoid carousels whose slides have different heights unless the container remains stable.
Test after fonts and personalised components load, not only in an initial screenshot. Scroll through longer pages and interact with expandable elements to find later shifts.
Mobile results deserve their own review
Mobile layouts use a different viewport and may choose different images. Phones can have less processing power and less reliable connections. A script that feels instant on a recent laptop can delay a tap on an older handset.
Read why a website may be faster on desktop than mobile and test on at least one real phone rather than relying solely on a desktop browser window resized to be narrow.
Frequently asked questions
Are Core Web Vitals the same as website speed?
They measure three important aspects of page experience, but website performance also includes server behaviour, additional rendering milestones, smoothness and the success of complete customer journeys.
Do small sites have Core Web Vitals data?
Not always in public Chrome field datasets. Insufficient data is not a failure. Use laboratory tools, real devices and any first-party monitoring available.
Can a plugin fix all three metrics?
A tool may improve caching or delivery, but it cannot reliably solve every cause. Measure before and after, check functionality and avoid overlapping optimisation plugins.
How quickly will field results change?
Public field data uses a rolling 28-day window, so improvements appear gradually. Use lab and manual checks for immediate validation.
Use the metrics to investigate problems
If reports disagree, compare PageSpeed Insights with Search Console by scope, device and time window. When the field section is empty, follow the no-real-user-data checklist rather than treating missing data as a failure.
Core Web Vitals give a shared language for loading, response and stability. Their value comes from connecting a metric to a real page, cause and customer task, then verifying that the improvement works.
Afterworks builds lightweight business websites with performance and usability considered together. Explore our website rebuild service or contact us if recurring template or platform constraints prevent meaningful improvement.
