Core Web Vitals, Explained for Business Owners

Google measures three things about how your pages feel to the people using them: how fast the main content appears, how quickly the page responds when someone taps it, and whether things jump around while it loads. Those three measurements are the Core Web Vitals. You'll meet them in PageSpeed Insights and Google Search Console, usually as a row of acronyms in red, orange and green.

This post covers what each one means, what counts as good, where to find your numbers and what fixes a bad one. My website audit checklist covers them in one table; this goes deeper.

One thing first. If a guide or a tool still talks about First Input Delay (FID), it's out of date. Interaction to Next Paint (INP) replaced FID as a Core Web Vital on March 12, 2024 (web.dev).

What the three measure

Largest Contentful Paint (LCP): loading

LCP is the time from when someone starts loading your page until the largest image, block of text or video in view has appeared (web.dev). Google notes that the largest element is typically an image or video, and sometimes a large block of text (Search Console Help). On a homepage with a big photo at the top, that photo is often what you're timing.

Interaction to Next Paint (INP): responsiveness

INP watches every click, tap and key press during a visit, and measures how long the page takes to show the result on screen: the menu opening, the button changing, the form moving to the next step. The final number is the slowest interaction, ignoring outliers. Scrolling and hovering don't count (web.dev).

FID, the metric it replaced, only measured the delay before the page started handling the first interaction. INP looks at every interaction, all the way until the screen updates. Google notes that many fewer sites pass INP than passed FID (web.dev), so a site that looked fine a few years ago may not anymore.

Cumulative Layout Shift (CLS): visual stability

CLS measures how much the content moves unexpectedly while someone is on the page. Google's examples: losing your place when the text you're reading suddenly moves, or tapping the wrong link or button because something loaded above it (web.dev). CLS is a score, not a time, and zero means nothing moved. Movement within half a second of a tap or click, like a menu you opened, is treated as expected and left out.

What counts as good

Google publishes the same three bands for each (web.dev, Search Console Help):

These aren't averages. Google judges each one at the 75th percentile of page loads, separately for phones and computers (web.dev). In plain terms, your LCP is good when at least three out of four visits saw the main content within 2.5 seconds. Google chose the 75th percentile so that pages work well for most visitors, including those on slow devices and poor connections (PageSpeed Insights documentation).

A page passes the Core Web Vitals assessment only when all three are good.

Do they affect your Google ranking?

Some. Google recommends that site owners achieve good Core Web Vitals, for success in Search and for a better experience generally, and says they line up with what its core ranking systems reward (Google Search Central).

But relevance comes first. Google says good scores don't guarantee your pages will rank at the top, that Search will still show the most relevant page even when its experience is poor, and that chasing a perfect score just for SEO "may not be the best use of your time" (Google Search Central).

The better reason to care is the people already on your site: a page that's slow or jumpy is worse for them, whatever it does for rankings.

How to check yours

PageSpeed Insights

Paste a page's address into PageSpeed Insights. It shows two kinds of results, and they answer different questions (PageSpeed Insights documentation).

The top section is field data: what real Chrome users experienced on that page over the previous 28 days, from Google's Chrome User Experience Report. This is the part that decides whether you pass. If the page doesn't have enough visits of its own, PageSpeed Insights falls back to your whole site. If the whole site doesn't have enough visitors either, there's no field data at all: the report only covers sites that are publicly discoverable and get enough visitors to make a meaningful sample (Chrome UX Report).

Below it is lab data: a test of one page load, run by Google's Lighthouse tool on a single simulated device and network. It's good for finding what's slow, but it isn't what your visitors experienced, so the two often disagree. The lab test can't measure INP, because nobody is tapping anything; Lighthouse reports Total Blocking Time instead (web.dev).

The performance score out of 100 comes from the lab test, and it can move between runs as conditions change (Lighthouse documentation). Watch the three measures, not the score.

Check both tabs, mobile and desktop. I'd start with mobile.

Search Console's Core Web Vitals report

PageSpeed Insights checks one address at a time. Google Search Console, a free service from Google (Search Console Help), has a Core Web Vitals report that covers your whole site, from the same real-user data (Search Console Help):

• Mobile and desktop are reported separately.
• Pages are grouped with similar pages, on the assumption that they're built the same way and share the same causes.
• Each group gets one label, Good, Need improvement or Poor, and it's the label of its worst measure. A group with poor CLS and good INP is Poor.
• "No data available" means either the property is new in Search Console, or there isn't enough real-user data for that device type.
• Fix Poor first. That's Google's own advice; Need improvement can wait.
• After a fix, click Start Tracking on the issue. Search Console then watches 28 days of data to see whether the problem is gone. It doesn't make Google recrawl anything.

If there's no field data

A small or new site may show no field data in either tool. Then use the lab results, where Total Blocking Time stands in for INP, and your own phone: open the site on cellular data, tap the menu and the main buttons, and watch whether anything jumps.

Common fixes

These come from Google's own guides to LCP, INP and CLS, plus its list of the most effective improvements.

When LCP is slow

• Size the main image for the screen. Serve it at the size it's shown, compressed, in a modern format, rather than the full-size file straight off a camera.
• Don't lazy-load it. Lazy loading holds an image back until the browser confirms it's on screen, so on the main image it only makes the browser wait. Marking it high priority (fetchpriority="high") does the opposite.
• Put it in the page's HTML. If the main image only appears through a stylesheet or a script, the browser finds it late.
• Speed up the first response. Cut chains of redirects, such as ad links that bounce visitors through several addresses, and serve pages from a content delivery network close to your visitors.

When INP is slow

A slow response means the browser was busy: with other work when the tap came in, with the code that handles the tap, or with redrawing the page afterward.

• Ship less JavaScript. The more JavaScript a page ships, the more tasks compete for the browser's attention, especially while the page is starting up. Look at what loads on every page (chat widgets, sliders, tracking tags, plugins) and remove what you don't use. If you use a tag manager, clear out old tags now and then.
• Break up long tasks. Any single job that runs longer than 50 milliseconds counts as a long task, and long tasks can stop the page from responding quickly. Splitting that work into smaller pieces is a developer's fix.
• Keep pages lean. A page with an enormous amount of markup takes more work to redraw after a tap.

When CLS is high

• Give every image and video a width and height, so the browser saves the space before it loads.
• Reserve space for anything that arrives late: ads, embedded maps and videos, booking widgets.
• Watch your fonts. When a custom font swaps in for the fallback font, the text can reflow and push things around.
• Animate with transforms. Animations that move things by changing their position on the page shift the layout. Transform animations, which move, scale or rotate an element, don't.

If your site runs on WordPress

The same fixes apply. Remove plugins you don't use, and run your key pages through PageSpeed Insights after updates, so you notice when something slows them down. My WordPress maintenance checklist includes a monthly speed check.

I also host and look after existing WordPress sites, on LiteSpeed servers I run, case by case. Tell me about yours and I'll send a written quote for hosting and upkeep before anything changes. Content and design changes aren't included. A $500 deposit starts the quote; it's refundable until you accept, and credited to the work. Ask for a quote.

Want me to look first?

Rather not read the reports yourself? My free audit is a five-minute video review of your homepage covering speed and mobile layout, SEO basics and calls to action, emailed to you within two business days. Request your audit.

Building a site that starts fast

I build plan sites in Next.js and host them on Vercel, and every plan includes "Mobile and speed optimized" alongside the design, on-page SEO and the rest (how I design and build sites). Next.js has two of the fixes above built into its image component: it serves correctly sized images in modern formats like WebP, and it prevents layout shift while images load (Next.js documentation).

I won't promise you a particular score. Field data depends on your visitors, their phones and connections, and what gets added to the site later.

Plans start at $2,400 for Starter, five pages, as one build fee. Pay in full for 10% off ($2,160), or half now and half before launch. The $79/mo care plan starts on launch day and covers hosting on Vercel with SSL, daily backups, uptime monitoring, and security and dependency updates. See the plans, or start your project.