Core Web Vitals are three measurements of how real visitors experience a page: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A page meets Google's "good" thresholds when, across at least 75% of visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less. They're worth getting right for your visitors' sake. Google says its ranking systems also use them, though relevance comes first.
The three Core Web Vitals and their thresholds
These are the current thresholds from web.dev's overview of Web Vitals and the individual metric pages, and they match what Search Console uses.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | how long until the main content appears | 2.5 s or less | up to 4 s | over 4 s |
| INP | how quickly the page reacts to a click, tap or key press | 200 ms or less | up to 500 ms | over 500 ms |
| CLS | how much visible content moves unexpectedly | 0.1 or less | up to 0.25 | over 0.25 |
Largest Contentful Paint (LCP)
LCP marks the moment the largest image, video poster or block of text in view finishes rendering. On most service-business homepages that's the hero photo or the main headline. A poor LCP is what a visitor experiences as staring at a blank or half-built screen.
Interaction to Next Paint (INP)
INP measures how long the page takes to show a visual response after someone clicks, taps or presses a key. Scrolling and hovering don't count. The value is roughly the slowest interaction in a visit, with a few outliers ignored on very busy pages. On a page with poor INP, someone taps "Book now", sees nothing happen, and taps again. INP replaced First Input Delay as a Core Web Vital in March 2024, so older reports that mention FID are out of date.
Cumulative Layout Shift (CLS)
CLS adds up how much visible content moves around unexpectedly. You go to tap "Call us", a banner loads above it, the page jumps, and you tap "Directions" instead. Shifts within half a second of a tap, click or key press are excluded, so a menu opening because you tapped it isn't penalised.
How a page passes or fails
Core Web Vitals are judged on what happens to real visitors. This real-user data (called field data) comes from the Chrome User Experience Report, and two details matter:
- The 75th percentile. A page passes a metric when at least three in four visits meet the "good" threshold. A few slow visits on a bad connection won't fail you; a slow experience for a quarter of your visitors will.
- Mobile and desktop are assessed separately. If most of your customers find you on their phones, the mobile result is the one to watch.
PageSpeed Insights shows field data from the previous 28 days. It says a page passes the Core Web Vitals assessment if the 75th percentiles of all three metrics are good, or LCP and CLS if there isn't enough INP data. If a single page doesn't have enough visits, it falls back to data for the whole site, and if the site doesn't either, it shows no real-user data at all. A site with modest traffic can easily land here, and it isn't a fault.
Below the field data, PageSpeed Insights runs a lab test with Lighthouse: one simulated load on a mid-range mobile device. It produces the familiar score out of 100, where 90 or above is good. Lab results are useful for finding problems, but they vary between runs and a good lab score doesn't guarantee a good real-user experience. When the two disagree, trust the field data.
How to check your own site
- Run your key pages through PageSpeed Insights. Include your main service page, your contact or booking page and a long article if you publish them, as well as the homepage. Look at mobile first.
- Read the real-user section before the score. If it says the page passes, you're in good shape whatever the lab number says.
- Open the Core Web Vitals report in Search Console. The report groups pages with a similar experience and gives each group the status of its slowest metric. After a fix, "Start Tracking" begins a 28-day check of whether the issue has gone.
- Use the site on a real phone. A mid-range Android handset over mobile data, on the MRT or in a lift lobby, tells you more than an office laptop on fibre.
- Write the results down. You'll want a baseline before any redesign or new feature, so you can tell whether it made things better or worse.
What slows a site down and how to fix it
Most problems come from a short list of causes. The fixes below follow web.dev's guide to the most effective ways to improve Core Web Vitals.
Slow LCP
Usual causes: an oversized hero image or an auto-playing video, a slider that loads five large images to show one, the main image loaded late by a page builder or set to lazy-load, and a slow server with no CDN.
Usual fixes:
- serve the main image as an ordinary image in the page's HTML, so the browser finds it straight away
- mark it as high priority (
fetchpriority="high") and never lazy-load it - resize and compress images for the sizes phones display
- serve the site from a CDN and cache pages, so the first byte arrives quickly
- defer anything not needed for the first screen
Poor INP
The usual cause is too much JavaScript: tracking tags that piled up over years of campaigns, a chat widget, pop-up tools, and heavy themes and plugins that load scripts on every page whether they're used there or not.
Usual fixes:
- audit and remove tags nobody uses any more
- load third-party widgets only on the pages that need them
- have a developer break up long tasks so the page can respond between them
- prefer built-in browser features over extra scripts that do the same job
High CLS
Usual causes: images and videos without set dimensions, embeds (booking widgets, maps, social feeds) that appear with no space reserved, web fonts that swap in at a different size, and cookie notices or promo bars inserted above the content.
Usual fixes:
- give every image a width and height, or an aspect ratio
- reserve space for embeds with a minimum height
- show cookie notices and promo bars as overlays, so they don't push content down
- animate with CSS transforms instead of changing position or size
A restaurant homepage with an auto-playing video and an embedded Instagram feed can struggle on LCP and CLS at once. A fitness studio whose class timetable is a late-loading third-party embed often shifts the whole page when it appears. Neither needs to be dropped; they need to be loaded with care. How much of this is in your control also depends on your platform, which WordPress vs website builders vs custom compares.
How much Core Web Vitals matter for search
Google is careful about what it claims here. Its page experience documentation says "Core Web Vitals are used by our ranking systems", but also that "there is no single signal" for page experience, that "Google Search always seeks to show the most relevant content, even if the page experience is sub-par", and that chasing a perfect score "just for SEO reasons may not be the best use of your time". Its Core Web Vitals page still recommends achieving good scores "for success with Search".
In practice, get every important page into "good" on mobile, then put the effort into content that answers your customers' questions. The larger cost of a slow site is usually the visitor who gives up before the page appears.
Speed also degrades over time. Each new tracking tag or widget adds a little, and enough of them will undo a fast launch. Checking the Search Console report every month or two as part of website maintenance catches it early, and comparing old and new before switching is a step in the website redesign SEO checklist.
Our website development work starts with phones, since speed is much harder to add to a site once it exists. If your current site is failing its Core Web Vitals and you'd like to know why, send us the address through contact.