Core Web Vitals: the no-jargon guide for business owners

Why does Google measure this?

Google wants to send its users to pages that are pleasant to use. Since 2021, it has therefore factored into its ranking three experience measurements called Core Web Vitals. It is not the most powerful signal in SEO, but it is a signal, and above all it is a conversion factor: a page that takes 6 seconds to display loses part of its visitors before it has shown anything at all.

The three metrics, translated

• LCP (Largest Contentful Paint), loading. Time to display the largest visible element, usually your main image or headline. It is the "the site is here" feeling. Target: 2.5 seconds or less.
• INP (Interaction to Next Paint), responsiveness. Delay between an action (click, typing) and the page's visible reaction. It is the "it responds" feeling. Target: 200 ms or less.
• CLS (Cumulative Layout Shift), stability. Measures layout shifts during loading, that moment when the button moves right as you were about to click it. Target: 0.1 or less.

The Lighthouse scale that goes with them is simple: a performance score of 90 to 100 is good, 50 to 89 needs watching, below 50 needs fixing.

Field or lab data?

There are two ways to measure, and they do not tell the same story. Field data (CrUX) is collected by Google from your real Chrome visitors over the last 28 days: it is the truth, but you need traffic to have any. Lab data (Lighthouse) is a simulation under standardized conditions: available for any site, but theoretical. Small sites often only have lab data; it is still an excellent indicator of where you stand. Our report always states which of the two sources it is showing.

Should you aim for 100/100?

No, and chasing 100 is one of the best ways to burn a budget. Two reasons.

First, what Google evaluates for ranking is the thresholds on the three metrics, not the Lighthouse score. A site with LCP at 2.3 s, INP at 150 ms and CLS at 0.05 is green across the board, whether its score reads 92 or 78. Taking that same site from 92 to 100 adds nothing to its ranking.

Second, the cost is not linear. Getting a page from 40 to 75 usually takes half a day and two or three simple moves: the images, the pointless scripts, compression. Going from 90 to 100 often means splitting stylesheets, removing features and dropping tools the business actually uses. The effort-to-gain ratio flips somewhere around 85.

So the right question is not "what is my score" but "am I green on all three thresholds, on mobile". If yes, the subject is closed, move on to content.

The 3 causes that show up everywhere

After dozens of audits of small-business websites, three causes explain the overwhelming majority of bad scores:

1. Oversized images. A photo straight out of a modern camera weighs 4 to 8 MB. Dropped as-is into a background image, it ruins your LCP single-handedly. Fix: resize to the actual display size and convert to WebP or AVIF. A hero image should weigh less than 200 KB.
2. Third-party scripts. Chat widget, tracking, external fonts, embedded videos: every third-party script potentially blocks the main thread. Fix: remove the ones no longer in use (there almost always are some), defer the loading of the others.
3. Underpowered hosting. If the server takes 1.5 seconds to respond before even sending the page, no optimization will make up for that delay. Fix: enable compression and server-side caching, or upgrade your plan. It is measured by TTFB (time to first byte, aim for under 600 ms).

How do you fix CLS without breaking things?

CLS is the most misdiagnosed of the three, because the culprit is rarely the one people accuse. An element can only shift the page if it enters the flow after the first paint. An absolutely positioned block, or a grid with fixed columns, shifts nothing, however much it animates and draws the eye.

The four real causes, by frequency:

• An image with no width or height. The browser does not know how much room to reserve, so it paints the text, then pushes everything down when the image lands. It is cause number one, and the easiest to fix.
• A hidden element that reappears. Watch the trap: hiding with the hidden attribute or display:none takes the element out of the flow. When it comes back, its neighbours rearrange. If the slot must stay reserved, use visibility:hidden, which keeps the space. We were caught by this on our own homepage, by a counter loaded after a network request.
• A banner inserted at the top of the page after the fact: it pushes the whole page down in one go.
• A custom font whose letters are not the same width as the fallback: the text reflows when the real font arrives.

The useful reflex before fixing anything: open your browser's Performance tab and look at which element moves. Fixing by guesswork costs days, as this very site can attest.

How long until Google takes it into account?

Here is the part nobody mentions, and the one that causes the most discouragement: Google's field data is a rolling 28-day average. The day you fix your images, the measurement barely moves, because it still contains 27 days of visits to the old version.

So allow roughly a month before the fix is fully reflected in Search Console, and do not conclude after one week that your work was wasted. Lab data, on the other hand, reacts instantly: measure the effect of your fix there the same day, then wait for the field data to confirm it.

How to measure your own site?

Our free audit queries Google's PageSpeed Insights API and displays your three metrics with their source (field or lab), integrated into the Performance category score. You can also use PageSpeed Insights directly: same data, without the rest of the audit. Measure the mobile version first: it is the one Google looks at, and it is almost always the worse of the two.