# Website speed and Core Web Vitals: what do they mean?

> A fast site keeps visitors. Google's three Core Web Vitals: LCP of 2.5 s or less, INP of 200 ms or less and CLS of 0.1 or less, for 75% of visits.

By Sotirios Terzis, Ariston Studios — updated 2026-10-10 — https://aristonstudios.com/guides/website-speed

## Key takeaways
- Core Web Vitals are three Google metrics for real-world user experience: loading (LCP), responsiveness (INP) and visual stability (CLS).
- A page passes when at least 75% of real visits are 'good': LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less.
- Google says Core Web Vitals are used by its ranking systems, but relevant, helpful content still matters more; speed is a tie-breaker, not a shortcut.
- The PageSpeed Insights score (0-100) is a lab test on a simulated phone. The field data from real Chrome users is what Google actually uses.
- Most slow small-business sites are fixed by compressing images, cutting third-party scripts, and moving to decent hosting.

Website speed is how quickly your pages load, respond to taps and settle into place on a visitor's device. Google measures it with three Core Web Vitals, and a page counts as fast when at least 75% of real visits meet the "good" thresholds for all three.

## Why does website speed matter for a business?

Speed matters first because of people, and only second because of Google. A visitor on a phone with a patchy connection does not wait politely: if the page is blank or jumps around, they go back and pick the next result. For a law firm, a plumber or a shop, that is a lost enquiry you never see.

On search, be precise about what Google actually says. Google Search Central states that Core Web Vitals are used by its ranking systems and recommends that site owners achieve good scores. It also says that good page experience is not a substitute for relevant content: Google will still show the most relevant page even if its page experience is weaker. In practice, speed helps you win close calls against similar pages. It will not make a thin page rank.

## What are the three Core Web Vitals?

Core Web Vitals are three metrics chosen by Google to describe how a page feels to a real user.

- **Largest Contentful Paint (LCP)** measures loading: how long until the biggest visible element, usually a hero image or headline, appears.
- **Interaction to Next Paint (INP)** measures responsiveness: how long the page takes to visibly react after someone taps, clicks or types. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024.
- **Cumulative Layout Shift (CLS)** measures visual stability: how much content unexpectedly moves while the page loads. It is a score, not a time.

## What are the official Core Web Vitals thresholds?

These are the thresholds published on web.dev. Each is assessed at the 75th percentile of page loads, separately for mobile and desktop. That means 75% of visits must be at or better than the "good" value.

| Metric | Good | Needs improvement | Poor |
| --- | --- | --- | --- |
| LCP (loading) | 2.5 s or less | 2.5 s to 4.0 s | over 4.0 s |
| INP (responsiveness) | 200 ms or less | 200 ms to 500 ms | over 500 ms |
| CLS (visual stability) | 0.1 or less | 0.1 to 0.25 | over 0.25 |

A page or site passes the Core Web Vitals assessment only when all three metrics are "good".

## What is the difference between lab data and field data?

Lab data comes from a test run on one simulated device and connection. Field data comes from real visitors.

- **Lab data**: PageSpeed Insights runs Lighthouse, which loads your page once on an emulated mid-range phone with a throttled connection. It is repeatable and useful for diagnosing problems, but it is one synthetic visit.
- **Field data**: the Chrome User Experience Report (CrUX) collects anonymised timings from real Chrome users who have opted in, over a rolling 28-day window. This is the data behind Google's Core Web Vitals assessment and the Core Web Vitals report in Search Console.

Small sites often have too little traffic to appear in CrUX. PageSpeed Insights will then show no field data for the page, or fall back to data for the whole domain. In that case, the lab results are your best guide.

## How do I test my website speed, step by step?

1. Open PageSpeed Insights (pagespeed.web.dev) and enter your home page URL.
2. Look at the top section first: "Discover what your real users are experiencing". If there is field data, check whether the Core Web Vitals assessment says Passed or Failed, and which metric is the problem.
3. Switch between the Mobile and Desktop tabs. Mobile is usually worse and matters most for local businesses.
4. Scroll to the lab section ("Diagnose performance issues") and read the Opportunities and Diagnostics. They name the exact files slowing you down.
5. Repeat for your two or three most important pages, such as a service page and the contact page, not just the home page.
6. If you use Google Search Console, open Experience, then Core Web Vitals, to see which groups of URLs fail across the whole site.

## What does the PageSpeed score mean, and what doesn't it mean?

The 0-100 performance score is a Lighthouse lab score. It is a weighted mix of five lab metrics (including LCP, CLS and Total Blocking Time) on a simulated phone. 90 to 100 is good, 50 to 89 needs improvement, and below 50 is poor.

What it does not mean:

- It is not what Google uses for ranking. The field data is.
- It varies between runs. A swing of a few points is normal.
- A 100 is not a goal in itself. A site that passes Core Web Vitals in the field with a lab score of 80 is in good shape.
- A low mobile score on a simulated slow phone does not mean every real visitor has a bad experience, but it does tell you where the weak points are.

## What are the most common causes of a slow website?

- **Oversized images.** A 4 MB photo straight from a camera or stock site, used as a hero image, is the most common cause of a slow LCP. Images should be resized to the size they display at and served in modern formats like WebP or AVIF.
- **Too many third-party scripts.** Chat widgets, tracking tags, heatmaps, social feeds, booking widgets and cookie banners each load their own code. Together they often hurt INP and loading more than the site itself.
- **Web fonts.** Several font families and weights downloaded from another server delay text and can cause layout shifts when the font swaps in.
- **Cheap or overloaded hosting.** A slow server delays everything. web.dev suggests a Time to First Byte of 0.8 seconds or less as a rough guide.
- **Heavy page builders and themes.** Many drag-and-drop builders load large amounts of code on every page, whether you use the features or not.
- **Layout shifts from ads, embeds and banners.** Ads, YouTube or map embeds, and images without set dimensions push content down as they load, which raises CLS.

## What should I ask my web developer?

- "Do our key pages pass Core Web Vitals in the field data, on mobile?"
- "Which metric is failing, and what is causing it?"
- "Which third-party scripts load on every page, and do we still need each one?"
- "Are images resized, compressed and served in WebP or AVIF, with width and height set?"
- "Is the hero image loaded with priority, and are images further down lazy-loaded?"
- "What is our server response time, and would better hosting or a CDN help?"
- "Who checks speed after changes, and how often?"

Speed is not a one-off job. New plugins, tags and photos slowly undo it, which is why ongoing checks belong in [website maintenance](/guides/website-maintenance).

## Which quick wins improve website speed?

| Quick win | Mainly improves | Effort |
| --- | --- | --- |
| Resize and compress images, use WebP or AVIF | LCP | Low |
| Set width and height on images and embeds | CLS | Low |
| Remove unused plugins, tags and widgets | INP, LCP | Low |
| Load chat and video embeds only when clicked | INP, LCP | Medium |
| Limit fonts to one or two families, host them yourself | LCP, CLS | Medium |
| Reserve fixed space for ads and cookie banners | CLS | Low |
| Move to better hosting or add a CDN | LCP | Medium |
| Replace a heavy page builder theme | All three | High |

## Where to start

Run PageSpeed Insights on your three most important pages, write down which metric fails, and fix images and third-party scripts first. Those two account for most problems on small business sites.

If you would rather have someone look for you, Ariston's [free website audit](/audit) combines Google Lighthouse data with a crawl of your site and emails you a report with the specific fixes. Our care plans can also include a monthly speed and uptime check.

## Frequently asked questions
### What is a good Core Web Vitals score?
A page is 'good' when, at the 75th percentile of real visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less. All three must be good to pass.

### Does website speed affect Google rankings?
Yes, but modestly. Google says Core Web Vitals are used by its ranking systems, while relevant, helpful content remains more important.

### Why is my PageSpeed score different every time I test?
The score comes from a single lab test, and network conditions, server load and third-party scripts vary between runs. Small swings are normal; look at trends and at field data instead.

### Why does PageSpeed Insights show no field data for my site?
Field data comes from the Chrome UX Report, which only includes pages and sites with enough real Chrome traffic. Smaller sites often fall below that threshold, so rely on the lab results.

### Do I need a PageSpeed score of 100?
No. Passing Core Web Vitals in the field data on mobile matters more than a perfect lab score. A score in the 90s is excellent; chasing the last few points rarely pays off.

## Sources
- [web.dev: Web Vitals](https://web.dev/articles/vitals)
- [web.dev: How the Core Web Vitals metrics thresholds were defined](https://web.dev/articles/defining-core-web-vitals-thresholds)
- [Google Search Central: Understanding Core Web Vitals and Google search results](https://developers.google.com/search/docs/appearance/core-web-vitals)
- [Google Search Central: Understanding page experience in Google Search results](https://developers.google.com/search/docs/appearance/page-experience)
- [Chrome for Developers: Lighthouse performance scoring](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring)
- [Chrome for Developers: Chrome UX Report overview](https://developer.chrome.com/docs/crux)
- [Search Console Help: Core Web Vitals report](https://support.google.com/webmasters/answer/9205520)
- [web.dev: Time to First Byte (TTFB)](https://web.dev/articles/ttfb)