Core Web Vitals explained for small business websites
Core Web Vitals are three measures Google uses to describe how a page feels to use: how quickly it loads, how quickly it responds and how stable it is. This guide explains each one without the jargon.
Short answer
Core Web Vitals are Largest Contentful Paint (loading, good at 2.5 seconds or less), Interaction to Next Paint (responsiveness, good at 200 milliseconds or less) and Cumulative Layout Shift (visual stability, good at 0.1 or less). Google assesses them at the 75th percentile of real page loads, separately for mobile and desktop.
What Core Web Vitals are
Web Vitals is a Google initiative that provides guidance on the quality signals that matter for a good experience on the web1. Core Web Vitals are the subset that apply to every web page. There are currently three, each covering a different part of how a page feels to use.
| Measure | What it describes | Good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading | Up to 2.5 seconds |
| Interaction to Next Paint (INP) | Responsiveness | Up to 200 milliseconds |
| Cumulative Layout Shift (CLS) | Visual stability | A score of 0.1 at most |
The thresholds come from web.dev's Web Vitals article1. Testing tools also show "needs improvement" and "poor" bands above these figures; check the tool you use for its current cut-off points.
Largest Contentful Paint: how quickly the page loads
LCP measures how long it takes for the largest piece of content in the visible part of the page to appear. On most business sites, that is a large image, a banner or the main heading. It is a practical stand-in for "when does the page look ready?"
Common causes of slow LCP
- A large banner image that has not been resized or compressed
- A slow server that takes a long time to send the first byte
- Fonts or scripts that must load before the page can display
- Images loaded with JavaScript instead of standard HTML
Fixes that usually help
- Resize the main image to the largest size it actually displays at, and use a modern format
- Tell the browser to load the main image early rather than lazily
- Reduce scripts and stylesheets that block the page from displaying
- Improve server response time, through caching or better hosting
Interaction to Next Paint: how quickly the page responds
INP measures how quickly a page responds when someone taps, clicks or types. It looks at the interactions during a visit and reports a value close to the slowest one. A page with poor INP feels sluggish: a menu that hesitates before opening, a button that seems to ignore the first tap.
Common causes of poor INP
- Heavy JavaScript that keeps the browser busy
- Third-party scripts such as chat widgets, advertising and multiple analytics tags
- Page builders that run large amounts of code on every page
- Complex animations triggered by scrolling
Fixes that usually help
- Remove scripts you no longer use
- Load non-essential scripts later, after the page is ready
- Replace heavy plugins with lighter alternatives
- Simplify or remove scroll-triggered effects
Cumulative Layout Shift: how stable the page is
CLS measures how much the page jumps around while it loads. You have probably experienced it: you go to tap a link and the page shifts just as an image or advert loads above it, so you tap the wrong thing. CLS adds up these unexpected movements into a single score.
Common causes of poor CLS
- Images and videos without set dimensions
- Adverts, banners or embeds that load late and push content down
- Web fonts that cause text to change size when they load
- Cookie or promotional banners that appear at the top and push the page down
Fixes that usually help
- Give every image and video a width and height
- Reserve space for embeds and banners before they load
- Choose font loading settings that minimise size changes
- Display banners as overlays at the bottom of the screen rather than pushing content
How Google assesses the measures
Two details matter when reading Core Web Vitals.
First, Google looks at the 75th percentile of page loads1. Put simply, at least 75 per cent of visits have to hit the target before Google rates the page good. A page that loads fast on your office broadband but slowly for a quarter of visitors on mobile data will not pass.
Second, mobile and desktop are assessed separately1. Mobile figures are usually worse, because phones are less powerful and connections slower. Pay most attention to mobile, since that is how many of your customers will see your site.
Lab data and field data
You will see two kinds of figures when testing.
Field data comes from real visitors using Chrome, collected over a rolling period. It is what Google uses to assess your pages. Small sites may not have enough visits to generate field data for every page.
Lab data comes from a simulated test run on demand. It is useful for diagnosing problems and checking fixes straight away, but it reflects one test on one simulated device, not your real visitors.
Use lab data to find and fix problems. Use field data to confirm whether fixes worked for real people, keeping in mind that it takes weeks to update.
How to check your own site
Free tools from Google show Core Web Vitals:
- PageSpeed Insights shows field data where available and runs a lab test for any address you enter.
- Search Console has a Core Web Vitals report that groups your pages by status, based on field data.
- Chrome's developer tools include a performance panel and Lighthouse, for detailed lab testing.
Start with PageSpeed Insights on your home page and a key service or product page, testing the mobile version.
Keeping it in perspective
Core Web Vitals are useful, but they are not everything. A fast page with unclear content will not win customers. A slightly slower page that answers a visitor's question clearly may serve them better. Treat the thresholds as a target for removing frustration, not as a score to chase for its own sake.
Be sceptical of anyone who promises a particular ranking improvement from speed work. Speed is one of many factors, and its effect varies. The dependable benefit is that fewer visitors give up waiting.
Where to start
If your pages fail one or more measures, start with the cheapest fixes:
- Resize and compress images, starting with the largest on each page.
- Add width and height to images.
- Remove plugins and scripts you no longer use. On WordPress, a WordPress redesign can cut plugin load at the source.
- Check your server response time; if it is slow, talk to your host.
If those do not get you to the thresholds, the problem may lie deeper, in the theme or platform. A performance clean-up or mobile redesign addresses those causes.
Core Web Vitals questions
Do Core Web Vitals affect search rankings?
Speed is only one of many things search engines weigh, and relevant, useful content matters far more. The case for speed work rests on visitors: faster pages frustrate fewer people, whatever happens to rankings.
Why does my site have no field data?
Field data requires a minimum number of visits from Chrome users. Smaller sites or less-visited pages may not reach it. Use lab data in the meantime.
Why are my mobile scores worse than desktop?
Phones generally have less processing power and slower connections than desktop computers, so the same page takes longer to load and respond. That is why mobile figures deserve the most attention.
Sources
Each source was opened and checked against the sentence it supports on 3 November 2026.
- Web Vitals Platform documentation
Ready to plan your redesign?
Tell us what your current site does well and what holds it back. You get a written, fixed quote in NZD before any work starts.