Core Web Vitals Explained for Business Owners

What Core Web Vitals are

Google describes Core Web Vitals as "a set of metrics that measure real-world user experience for loading performance, interactivity, and visual stability of the page" (Google Search Central). There are three:

• Largest Contentful Paint (LCP): loading. How long it takes for the biggest piece of content in view, usually a hero image or the main heading, to appear.
• Interaction to Next Paint (INP): responsiveness. How quickly the page visibly reacts when someone taps a button, opens a menu or types in a form, measured across the whole visit. INP replaced the older First Input Delay metric on 12 March 2024, so older articles that mention FID are out of date.
• Cumulative Layout Shift (CLS): visual stability. How much the content moves around unexpectedly while the page loads, such as text that jumps down when an image or banner appears above it.

The thresholds

Google's web.dev guide sets these targets for a good experience:

• LCP: within 2.5 seconds of the page starting to load.
• INP: 200 milliseconds or less.
• CLS: 0.1 or less.

The PageSpeed Insights documentation also gives the upper bands: LCP over 4 seconds, INP over 500 milliseconds and CLS over 0.25 count as poor, with "needs improvement" in between.

Two details matter when you read your results. First, the scores are judged at the 75th percentile of real page loads, separately for mobile and desktop: a page passes when at least three out of four visits meet the target. Second, a page needs to pass all three metrics. A fast page that jumps around still fails.

How to check your site

Both of these tools are free and come from Google.

PageSpeed Insights

Paste any URL into PageSpeed Insights. It shows two kinds of data, and it is worth knowing the difference:

• Field data comes from real Chrome users over the previous 28 days (the Chrome User Experience Report). This is the data that counts. A new or low-traffic page may not have enough visits for its own figures; PageSpeed Insights then shows figures for the whole site, or none at all.
• Lab data is a single test run in a controlled environment. It is useful for finding problems and checking a fix, but it may not match what real visitors experience, and the 0-100 performance score is a lab score, not a Core Web Vitals result.

Search Console's Core Web Vitals report

If your site is verified in Search Console, the Core Web Vitals report groups similar pages together and marks each group Good, Need improvement or Poor, separately for mobile and desktop, based on real-user data. A group's status is set by its worst metric. Smaller sites often see "No data available": that means there is not yet enough real-user data, not that something is wrong. Use PageSpeed Insights on your key pages instead.

Start with the pages that matter most to your business: the home page, your main service or product pages, and any landing page you pay to send traffic to. Check the mobile results as well as desktop; they are reported separately.

Fixing slow loading (LCP)

The web.dev LCP guide breaks slow loading into stages, starting with how long the server takes to send the first byte of the page. The usual fixes:

• Make the main image light. Serve it at the size it is shown, in a modern format, and compressed. A photo straight from a camera can be many times larger than it needs to be.
• Do not lazy-load the main image. Lazy loading is good for images further down the page, but it delays the one visitors see first.
• Speed up the server. Page caching, adequate hosting and, for a content management system, fewer heavy plugins all reduce the wait before anything appears.
• Cut what blocks the first render. Large stylesheets, scripts and fonts loaded before the content all delay it.

Fixing slow responses (INP)

Slow responses almost always come from too much JavaScript keeping the browser busy, so it cannot react to a tap. The web.dev INP guide covers the technical detail; in practice:

• Review third-party scripts. Chat widgets, tracking tags, social embeds and pop-up tools each add work. Remove the ones nobody uses and load the rest later where you can.
• Trim plugins and page-builder add-ons that load scripts on every page for features used on one.
• Split long tasks. For custom code, developers can break heavy work into smaller pieces so the page can respond in between.

Fixing layout shifts (CLS)

According to the web.dev CLS guide, the most common causes are images without dimensions, ads, embeds and iframes without dimensions, content injected after the page loads, and web fonts. The matching fixes:

• Give every image and video a width and height (or an aspect ratio), so the browser keeps space for it.
• Reserve space for embeds and ads, such as maps, videos and booking widgets.
• Do not push content down with banners or notices that appear above it after loading; overlay them or reserve their space.
• Load fonts carefully, so text does not reflow when the web font arrives.

Many of these are checked as part of our website launch checklist, and they drift over time as plugins, scripts and content are added, which is why speed is part of ongoing website care.

What they do for search rankings

Google is clear on both sides. On one hand, "Core Web Vitals are used by our ranking systems", and Google recommends that site owners achieve good scores. On the other, from the same page experience documentation:

• Getting good results in Search Console or other tools "doesn't guarantee that your pages will rank at the top of Google Search results".
• Google "always seeks to show the most relevant content, even if the page experience is sub-par". Page experience helps most when many pages are similarly helpful.
• Chasing a perfect score "just for SEO reasons may not be the best use of your time".

In short: get your key pages into the "good" range, then put your effort into content that answers what your customers search for. Our SEO basics guide covers that side. A fast, stable page is also simply easier to use, and that matters to every visitor, not only to Google.

Frequently asked questions

What are good Core Web Vitals scores?

Google's targets for a good experience are LCP within 2.5 seconds, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile of real page loads on mobile and on desktop.

Why is my PageSpeed Insights score different every time I test?

The 0-100 score comes from a single lab test, which varies with network and server conditions on each run. The real-user field data at the top of the report changes slowly, because it covers the previous 28 days.

Why does Search Console say "No data available" for Core Web Vitals?

There is not enough real-user data for your site yet, which is common for new or smaller sites. Test your key pages in PageSpeed Insights instead.

Do Core Web Vitals affect my Google ranking?

Google says Core Web Vitals are used by its ranking systems, but good scores do not guarantee top rankings, and relevant, helpful content comes first. Aim for good scores on your key pages rather than a perfect number.

How long after a fix will my scores improve?

Lab tests show the change immediately. Field data covers the previous 28 days, so real-user figures in PageSpeed Insights and Search Console improve gradually over the following weeks.

Want a second pair of eyes on your site's speed? See what website care covers and how we approach website development, or email info@creahive.com with your web address.