Guide
Core Web Vitals explained for business owners
What Google's three Core Web Vitals measure, the exact thresholds, how to read your own report, and the fixes that usually move each number. Plain language, no developer jargon.
VAULT 33|27 · Updated 12 November 2026 · Reviewed 12 November 2026 · 4 min read
In one minute
Core Web Vitals are three measurements Google uses to judge how a page feels to a real visitor: how fast the main content appears, how quickly the page reacts when someone taps, and whether things jump around while it loads. They matter for two reasons. Visitors leave slow, jumpy pages before they enquire, and Google uses page experience as one of many signals in search.
The three numbers and the targets
| Metric | What it measures in plain words | Good |
|---|---|---|
| Largest Contentful Paint (LCP) | How long until the main content, usually the hero image or headline, is visible | 2.5 seconds or less |
| Interaction to Next Paint (INP) | How quickly the page responds after someone taps, clicks or types | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much the layout jumps while loading, for example a button moving as an image loads | 0.1 or less |
Google assesses each metric at the 75th percentile of real page loads, separately for mobile and desktop. In practice: three out of four of your visitors need a good experience for the page to pass. INP replaced the older First Input Delay metric as a Core Web Vital in 2024, so older articles that mention FID are out of date.
Lab data versus real visitors
Most people misread their speed report because it mixes two kinds of data.
| Lab data | Real-visitor (field) data | |
|---|---|---|
| Where it comes from | A simulated test on one device and connection | Chrome users who visited your site over the last 28 days |
| What it is good for | Finding causes and testing fixes | Knowing what your visitors actually experience |
| What Google uses for page experience | Not directly | Yes |
| Why it can look different | One test, one moment | Thousands of visits on real phones and networks |
If your site is small, Google may not have enough real-visitor data yet. Then the lab test is your best guide, but treat its score as a direction, not a verdict. Lab scores also vary between runs.
How to check your own site in two minutes
- Open PageSpeed Insights and enter your most important page, usually the homepage or your best service page.
- Look at the top box first. If it says real-user data is available, that is what matters most.
- Switch between Mobile and Desktop. Most service businesses get most visitors on mobile, so fix mobile first.
- Scroll to Diagnose performance issues to see the causes.
Or run the VAULT Business Audit, which runs Google's mobile test and checks your enquiry paths and search basics in the same report.
What usually fixes each metric
| If this is poor | The usual causes | The usual fixes |
|---|---|---|
| LCP (slow main content) | Huge hero images, slow hosting, sliders, render-blocking scripts and fonts | Resize and compress the hero image (modern formats such as WebP or AVIF), load it with high priority, faster hosting or caching, remove sliders |
| INP (slow to react) | Heavy JavaScript, page builders, too many third-party scripts such as chat, tracking and widgets | Remove scripts nobody uses, load third-party tools later, lighter theme or rebuild |
| CLS (jumping layout) | Images without set dimensions, late-loading banners, cookie bars and fonts that swap | Give images and embeds fixed sizes, reserve space for banners, use font loading that does not shift text |
When a rebuild beats patching
Patching works when the problems are a few large images or a handful of scripts. A rebuild is usually cheaper in the long run when the site is built on a heavy page builder, has dozens of plugins, or fails on every page. A rule of thumb we use: if fixing the homepage takes more than a few days and the next page has the same problems, the platform is the problem.
What this does not mean
Passing Core Web Vitals will not lift a weak page to the top of Google on its own. Relevance and helpful content still decide most rankings. But a slow page loses visitors who were ready to enquire, and that cost appears whether or not rankings change.
Checklist
- Test mobile and desktop for your top five pages, not only the homepage.
- Fix the hero image on every key page first. It is the most common cause of slow LCP.
- List every third-party script and remove the ones nobody uses.
- Set width and height on all images and embeds.
- Re-test after each change, and check real-visitor data again after 28 days.
Sources
Open your vault.
A free systems audit of your business: where enquiries leak and exactly what we would build.
Book your free audit