Core Web Vitals: A Business Owner's Guide

Core Web Vitals are three measurements Google uses to describe how a page feels to real visitors: how fast the main content appears, how quickly the page responds to taps and clicks, and how stable the layout is while loading. They matter to business owners mainly because slow, jumpy pages are frustrating to use. Google does use them in ranking, but it is clear that they are one input among many.

This guide explains each metric, how to measure it, what Google actually says about search impact, and which fixes tend to matter first.

The three metrics and their thresholds

web.dev defines each metric and a “good” threshold, assessed at the 75th percentile of page loads, segmented by mobile and desktop (web.dev: Web Vitals).

Metric	What it measures	Good	Needs improvement	Poor
Largest Contentful Paint (LCP)	Loading: when the main content appears	2.5 s or less	up to 4 s	over 4 s
Interaction to Next Paint (INP)	Responsiveness to taps, clicks and key presses	200 ms or less	up to 500 ms	over 500 ms
Cumulative Layout Shift (CLS)	Visual stability: unexpected movement	0.1 or less	up to 0.25	over 0.25

The “needs improvement” and “poor” bands above come from the Search Console help page for the Core Web Vitals report (Search Console Help: Core Web Vitals report).

The 75th percentile matters. A page passes only when at least three in four visits meet the threshold, so a few fast tests on your own laptop do not prove the experience is good for everyone.

What Google says about ranking

Google’s page experience documentation states that Core Web Vitals are used in ranking and recommends good scores, but also that good results do not guarantee top rankings. It says there is no single page experience signal, that Google “always seeks to show the most relevant content, even if the page experience is sub-par”, and that chasing perfect scores only for SEO may not be the best use of your time (Google Search Central: page experience).

The sensible reading: treat Core Web Vitals as a quality floor, not a lever that will leapfrog a competitor with better content. Get into the “good” range, then spend effort on content, usability and conversion. Our guide to what makes a business website convert covers those next steps.

How to measure: field data first

There are two kinds of data, and mixing them up causes confusion.

Field data comes from real users. Both PageSpeed Insights and Search Console draw on the Chrome User Experience Report (CrUX). PageSpeed Insights shows real-user metrics over the previous 28 days, classified at the 75th percentile, and falls back to origin-level data when a page lacks enough traffic (Google PageSpeed Insights: about).
Lab data comes from a simulated test using Lighthouse on one device and network setup. It is useful for diagnosing problems but can differ from field results.

Search Console’s Core Web Vitals report groups URLs by status (Good, Need improvement, Poor), by metric and by device. A group takes the status of its slowest metric, and only indexed URLs appear, as a sample rather than every page (Search Console Help). Small sites may see no data at all if traffic is too low, in which case use PageSpeed Insights lab results and your own testing on a mid-range phone.

A simple routine:

Run your home page, top service page and top content page through PageSpeed Insights.
Read the field data section first. If it passes on mobile, you are in good shape.
If it fails, note which metric, then use the lab diagnostics to find causes.
Recheck after changes. Field data updates over a rolling window, so improvements take weeks to show fully.

Fixing LCP: get the main content out quickly

web.dev splits LCP into four parts: time to first byte, resource load delay, resource load duration and element render delay. A well-optimised page spends most of its time on the first and third, with the delays kept small. It also warns that fixing one part can shift time into another, so improve them together (web.dev: optimize LCP).

Practical fixes for business sites:

Put the main hero image in the page’s HTML as a normal image, not a CSS background or something injected by script, so the browser finds it early.
Add fetchpriority="high" to the likely LCP image, to one or two images only.
Never lazy-load the LCP image.
Serve appropriately sized, compressed images in modern formats.
Reduce redirects and use caching or a CDN to cut time to first byte.
Avoid render-blocking scripts and large stylesheets in the head.

If you use WordPress, page caching and removing unneeded plugins are the usual first steps. See our Astro vs WordPress comparison for how platform choice affects these defaults.

Fixing INP: keep the main thread free

INP is about how long the page takes to visibly respond after a tap, click or key press. web.dev points to long main-thread tasks, often from JavaScript parsing and execution, as a primary cause, and recommends yielding to the main thread, doing as little work as possible in event handlers and keeping the DOM small (web.dev: optimize INP).

For a business site this often means:

Audit third-party scripts: chat widgets, tag managers loaded with many tags, social embeds, heatmaps. Remove what you do not use.
Load scripts only when needed (on interaction or when scrolled into view) rather than on every page.
Be wary of heavy animation libraries and large client-side rendered components for simple content. See building interactive websites for how to add interactivity without the cost.

Fixing CLS: stop things jumping

web.dev’s layout shift guidance is straightforward (web.dev: optimize CLS):

Set width and height attributes on images and video, or reserve space with CSS aspect-ratio.
Handle web fonts carefully: preload critical fonts, use font-display: optional where appropriate and a close fallback font to minimise re-layout.
Reserve space for ads, embeds, cookie banners and forms, or overlay them so they do not push content down.
Animate with transform rather than layout properties such as top and left.

The most common cause on small business sites is an image or banner without reserved space.

Prioritising when you have limited time

Fix the worst metric on your top landing pages first. Pages that receive the most visits or paid traffic matter most.
Start with images and third-party scripts. They are the most common causes and often the cheapest to fix.
Set a performance rule for new content. For example, every image needs dimensions and compression before upload.
Monitor monthly. Regressions creep in through new plugins, tags and banners.

Where Radiance Impact fits

Radiance Impact’s Technology division builds and maintains business websites, including performance work on existing sites and ongoing care. If you want help interpreting a failing report or planning fixes, see our Technology services or contact us.

Sources

Web Vitals, web.dev (Google)
Optimize Largest Contentful Paint, web.dev (Google)
Optimize Interaction to Next Paint, web.dev (Google)
Optimize Cumulative Layout Shift, web.dev (Google)
Understanding page experience in Google Search results, Google Search Central
Core Web Vitals report, Google Search Console Help
About PageSpeed Insights, Google for Developers