What Are Core Web Vitals? A Business Owner's Guide

If you have ever wondered why your website ranks below a competitor's despite having better content, the answer might be three metrics you have never heard of. They are called Core Web Vitals, and since 2021, Google has used them as a direct ranking signal. Not an indirect one. Not a tiebreaker. A factor that actively influences where your pages appear in search results.

The good news: Core Web Vitals are not mysterious. They measure three specific things your visitors experience every time they load a page. Once you understand what they are and what causes them to go wrong, fixing them is straightforward. This guide explains everything in plain language — no developer background required.

What Are Core Web Vitals?

Core Web Vitals are a set of three performance metrics that Google considers essential to a good user experience on the web. They were introduced as part of Google's Page Experience update and have been a confirmed ranking factor since June 2021.

The three metrics each measure a different dimension of user experience:

Largest Contentful Paint (LCP) — loading performance
Interaction to Next Paint (INP) — interactivity and responsiveness
Cumulative Layout Shift (CLS) — visual stability

Together, they answer three questions that every visitor subconsciously asks: Does this page load quickly? Does it respond when I interact with it? Does it stay still while I am trying to use it?

Why Google Uses Core Web Vitals for Ranking

Google's business model depends on sending users to pages that satisfy their intent. If Google consistently ranks slow, glitchy, or unstable pages at the top, users will eventually switch to a search engine that does not. Core Web Vitals give Google a measurable, standardized way to evaluate whether a page delivers a good experience — independent of its content quality.

This means two pages with identical content quality will not rank equally. The one with better Core Web Vitals will have an edge. For competitive keywords where dozens of pages offer similar information, that edge can be the difference between page one and page two. And the difference between page one and page two is the difference between getting traffic and not.

Google collects Core Web Vitals data from real Chrome users through the Chrome User Experience Report (CrUX). This is not lab data from a simulation. It is field data from actual people visiting your site on their actual devices and connections. You cannot game it with a perfectly optimized test environment that does not reflect reality.

LCP: Largest Contentful Paint

What It Measures

LCP measures how long it takes for the largest visible content element on the page to finish rendering. This is usually a hero image, a large text block, or a video poster image. It captures the moment when a visitor perceives that the page has mostly loaded — the point where they think, "OK, the content is here."

The Thresholds

Good: 2.5 seconds or faster
Needs improvement: 2.5 to 4.0 seconds
Poor: Slower than 4.0 seconds

What Causes Poor LCP

Four issues account for the vast majority of LCP problems:

Slow server response times. If your server takes more than 200 milliseconds to respond to a request (measured by Time to First Byte), everything else is delayed. Cheap shared hosting is a common culprit.
Unoptimized images. A 3 MB hero image that could be 150 KB in WebP format will drag your LCP down on every visit. This is the single most common cause of poor LCP scores.
Render-blocking resources. CSS and JavaScript files that must be fully downloaded and parsed before the browser can display any content. Every extra stylesheet or script in the document head adds delay.
Client-side rendering. Single-page applications built with React, Vue, or Angular that render content in the browser rather than on the server often have LCP issues because the browser has to download JavaScript, execute it, and then render the content — three steps instead of one.

How to Improve LCP

Compress and resize images. Convert to WebP or AVIF. Never serve an image larger than its display size.
Use a Content Delivery Network (CDN) to reduce server response time for visitors far from your hosting location.
Preload the LCP element using <link rel="preload"> so the browser fetches it early.
Minimize render-blocking CSS and JavaScript. Inline critical CSS and defer everything else.
If using a JavaScript framework, implement server-side rendering or static generation.

INP: Interaction to Next Paint

What It Measures

INP replaced First Input Delay (FID) as the responsiveness metric in March 2024. While FID only measured the delay before the browser could start processing the very first interaction, INP measures the responsiveness of every interaction throughout the entire page visit — clicks, taps, and key presses — and reports the worst one (with some outlier filtering).

In practical terms, INP answers the question: "When I click something, does it respond immediately or does it freeze?" Every time a user taps a menu button and waits 400 milliseconds for it to open, that registers as poor responsiveness. Every time a form field takes half a second to accept a keystroke, trust erodes.

The Thresholds

Good: 200 milliseconds or faster
Needs improvement: 200 to 500 milliseconds
Poor: Slower than 500 milliseconds

What Causes Poor INP

INP problems are almost always caused by JavaScript. Specifically:

Long tasks on the main thread. When JavaScript runs for more than 50 milliseconds without yielding, the browser cannot process user input until the script finishes. Third-party scripts — analytics, ad networks, chat widgets — are frequent offenders.
Excessive DOM size. Pages with thousands of DOM elements take longer to update after interactions because the browser must recalculate layout and repaint a larger tree.
Expensive event handlers. Click or scroll handlers that trigger complex calculations, large DOM mutations, or synchronous network requests will block responsiveness.

How to Improve INP

Audit third-party scripts aggressively. Remove any that are not directly contributing to revenue or critical functionality.
Break long JavaScript tasks into smaller chunks using requestIdleCallback or setTimeout to yield to the main thread.
Reduce DOM size. If your page has more than 1,400 elements, look for opportunities to simplify.
Debounce expensive event handlers so they do not fire on every interaction.
Use web workers to move heavy computation off the main thread entirely.

CLS: Cumulative Layout Shift

What It Measures

CLS measures how much the visible content on a page shifts around unexpectedly while loading. You have experienced this: you start reading an article, an ad loads above the text, and the paragraph you were reading jumps down the page. Or you go to tap a button, the layout shifts, and you accidentally tap something else entirely.

CLS quantifies that frustration. It calculates how much of the viewport was affected by unexpected shifts and how far elements moved. A CLS score is unitless — it is a product of the impact fraction (how much of the viewport shifted) and the distance fraction (how far things moved).

The Thresholds

Good: 0.1 or lower
Needs improvement: 0.1 to 0.25
Poor: Above 0.25

What Causes Poor CLS

Images and videos without dimensions. When you do not specify width and height attributes, the browser does not know how much space to reserve. The content loads, the image appears, and everything below it jumps down.
Ads and embeds that load late. Third-party content injected after the initial page render pushes existing content around.
Web fonts that cause FOUT. When a custom font loads and replaces a fallback font with different character widths, text reflows and shifts surrounding content. This is called Flash of Unstyled Text.
Dynamically injected content. Banners, cookie consent notices, and notification bars that insert themselves above existing content without reserving space in advance.

How to Improve CLS

Always include width and height attributes on images and video elements, or use CSS aspect-ratio to reserve space.
Reserve fixed space for ads and embeds using CSS. Even if the ad has not loaded, the space should be held.
Use font-display: swap with size-adjusted fallback fonts to minimize text reflow when custom fonts load.
Avoid inserting content above existing content after the page has rendered. If you must show a banner, push it from the top before anything else loads, or overlay it without shifting content.

How to Check Your Core Web Vitals

You have several options for checking your scores:

Google Search Console. The Core Web Vitals report shows your site-wide performance using real user data. This is the most authoritative source because it is the same data Google uses for ranking.
PageSpeed Insights. Enter any URL and get both field data (real users) and lab data (simulated). Field data is what matters for ranking; lab data is useful for debugging.
Chrome DevTools. The Performance panel lets you measure all three metrics in real time as you interact with the page. Useful for isolating specific issues.
Web Vitals Extension. A Chrome extension that displays your Core Web Vitals in real time as you browse. Great for quick spot checks.

For the fastest assessment, run a free Claros scan. You will get your Core Web Vitals scores, a performance grade, and specific recommendations — in under 30 seconds with no account required.

What Scores Should You Aim For?

Google evaluates Core Web Vitals at the 75th percentile of page loads. This means 75% of your visitors need to have a good experience for the page to pass. It is not enough for your site to be fast for visitors on fiber connections with high-end devices. It needs to be fast for the person on a three-year-old phone using cellular data at a coffee shop.

The target is clear: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. Hit all three, and Google classifies your page as having a good experience. Miss any one of them, and you lose the ranking benefit.

If you are currently in the "needs improvement" range, the priority is to get to "good." If you are in the "poor" range, the impact of improvement will be even more dramatic — both on rankings and on actual user behavior. People can feel the difference between a 4-second load and a 2-second load. They will stay longer, click more, and convert at higher rates.

Core Web Vitals Are a Competitive Advantage

Here is the reality: most small business websites have mediocre Core Web Vitals. They are built on bloated WordPress themes with unoptimized images, a dozen plugins, and three analytics scripts. That is the baseline you are competing against.

If you get your Core Web Vitals into the "good" range — all three of them — you gain an advantage over the majority of your local competitors. Not a hypothetical advantage. A measurable one, reflected in search rankings, bounce rates, and conversion rates.

Start by finding out where you stand. Run a free scan to see your current Core Web Vitals scores and get a prioritized list of what to fix first.