Core Web Vitals, explained

Core Web Vitals are three measurements Google uses to judge how a page feels to use: how quickly the main content appears, how quickly the page reacts when someone taps or types, and whether things jump around while it loads. They are part of how Google assesses page experience, and they line up closely with what makes visitors stay or leave.

This guide explains each one in plain terms, gives the thresholds Google publishes, and covers the fixes that tend to make the biggest difference on the business websites we build and look after.

What Core Web Vitals measure

There are three metrics, each covering one part of the experience:

Two details matter more than the numbers themselves:

• Google measures real visitors. The thresholds apply to field data from Chrome users over the previous 28 days, not to a test you run once.
• A page passes at the 75th percentile. At least three out of four visits need to be in the “good” range for that metric. Fast for you on office Wi-Fi is not the same as fast for a customer on a phone with two bars of signal.

Google documents all of this on web.dev, which is the reference to check if anything here ever changes.

Largest Contentful Paint

LCP marks the moment the largest image or block of text in the first screen finishes rendering. On most business sites that is the hero image, a large headline or a product photo.

When LCP is slow, the cause is almost always one of four things:

1. A slow server response. If the HTML itself takes a second to arrive, everything else starts late. Good hosting, page caching and a CDN fix most of this.
2. The LCP element is discovered late. An image set as a CSS background, loaded by a slider script, or marked loading="lazy" above the fold makes the browser find it too late.
3. Heavy files. A 2 MB hero photo will never load in time on a phone. Serve modern formats (AVIF or WebP), size images to the space they fill and use responsive srcset sizes.
4. Render-blocking CSS and JavaScript. Large theme and plugin bundles must download and run before anything appears.

The quickest wins are usually to compress and correctly size the hero image, remove lazy loading from it, add fetchpriority="high" to it, and cut plugins that load scripts on every page.

Interaction to Next Paint

INP measures how long it takes from a visitor’s tap, click or key press until the screen visibly responds. It looks across the whole visit and reports one of the slowest interactions, so a single sluggish menu or filter can drag it down.

INP replaced First Input Delay as a Core Web Vital in March 2024, and it is the metric many WordPress sites now fail, because the cause is JavaScript that keeps the browser busy:

• Too many third-party scripts. Chat widgets, heatmaps, multiple analytics tags and social embeds all compete for the same main thread.
• Heavy page builders and sliders. Large frameworks run a lot of code on every interaction.
• Long tasks. Any single piece of JavaScript that runs for more than 50 ms blocks the page from responding in that time.

Fixes that work: remove scripts you do not use, load the ones you keep only on the pages that need them, delay non-essential widgets until after the page is interactive, and replace heavy components (sliders, mega-menus built in JavaScript) with simpler HTML and CSS.

Cumulative Layout Shift

CLS adds up how much visible content moves unexpectedly while someone is using the page. Everyone has tried to tap a link just as an advert loads above it and pushes the page down; that is layout shift.

The common causes are easy to spot once you look for them:

• Images and videos without dimensions. Without width and height (or an aspect ratio), the browser cannot reserve space, so content jumps when the file arrives.
• Banners and embeds that appear late. Cookie notices, promo bars and ad slots injected at the top push everything down.
• Web fonts swapping in. A fallback font with different proportions makes text reflow when the real font loads.

Set dimensions on every image and embed, reserve space for anything that loads late, show banners as overlays rather than inserting them above content, and use font fallbacks with matching metrics.

How to check your site

You can see where you stand in a few minutes, without any paid tools:

1. PageSpeed Insights (pagespeed.web.dev): enter a URL. The top section shows field data from real visitors if your site has enough traffic; the lower section is a Lighthouse lab test that helps you find causes.
2. Google Search Console: the Core Web Vitals report groups your URLs into good, needs improvement and poor, separately for mobile and desktop, and tells you which pages share the same problem.
3. Chrome DevTools: the Performance panel shows live LCP, INP and CLS values as you use the page, which is the fastest way to find the slow interaction or the element that shifts.

Check mobile first. Most visitors to most small-business sites are on phones, and that is where the thresholds are hardest to meet.

The fixes that matter most

If you only have time for a handful of changes, these usually move the numbers the most:

• Compress and correctly size the main image on each key page, and do not lazy-load it.
• Turn on page caching and serve the site through a CDN.
• Remove plugins and third-party scripts you no longer use; load the rest only where needed.
• Give every image, video and embed a width and height.
• Show cookie notices and promo bars as overlays, not inserted above content.
• Preload your main web font and use a fallback with similar proportions.
• Re-test in PageSpeed Insights and watch the Search Console report over the next 28 days.

Speed is easiest to get right when a site is designed for it from the start, which is why we treat it as part of web design rather than something bolted on after launch. If your current site is struggling, our technical SEO guide covers the wider checks, and our SEO team can tell you whether a tune-up or a rebuild is the better investment.