Skip to content
Back to blog

Core Web Vitals Guide: How to Read Google's Speed Report Card

·6 min read·Vucod

Core Web Vitals is the speed report card Google keeps on your website — and most site owners have either never seen it or seen it and understood nothing. That's not their fault. Sentences like "LCP should be under 2.5 seconds and CLS under 0.1" communicate nothing without translation. This core web vitals guide is that translation: what each of the three metrics actually measures, where to read your report card, which grades matter, and how bad ones get fixed.

Why should you care about Core Web Vitals?

Two reasons. The first is Google: Core Web Vitals is one of its ranking signals. It won't carry you to page one on its own — content and authority weigh more — but in a close race, the slow site loses. People who inflate the speed signal are wrong; so are people who dismiss it.

The second reason is more concrete: these metrics measure the experience your visitors are already having. If the page arrives late, if a tap gets no response, if the content jumps just as they're about to click — your visitors notice before Google does, and some of them leave. The report card isn't really kept for Google. It's kept for you.

Three metrics, three questions

Core Web Vitals consists of three metrics, and each one answers a question your visitor is silently asking.

LCP — "When did the page arrive?"

Largest Contentful Paint is the time until the biggest visual element on the page — usually the hero image or the main headline — appears on screen. It's the metric that matches the visitor's feeling of "the site has loaded." Google's threshold: under 2.5 seconds is good; over 4 seconds is poor.

The usual suspects behind a bad LCP: enormous uncompressed images, slow server response, a pile of scripts blocking the page, and well-intentioned optimizations applied in the wrong place — like lazy-loading. Yes: putting lazy load on the image at the very top of the screen is the classic way to slow a page down while trying to speed it up.

INP — "I clicked. Did it respond?"

Interaction to Next Paint measures how long the screen takes to react when a visitor clicks, taps, or types. It replaced the older FID metric in 2024 and is a much tougher judge, because it considers every interaction across the page's lifetime, not just the first one. Threshold: under 200 milliseconds is good.

INP's chief enemy is JavaScript keeping the browser busy: analytics tags, marketing pixels, heavy menu animations, third-party chat bubbles. The page looks loaded, but freezes when clicked — and that's the exact moment visitors lose trust fastest.

CLS — "Did the floor just move under me?"

Cumulative Layout Shift measures how much the content jumps around while the page loads. The paragraph sliding down mid-sentence, the ad popping in just as you press "Confirm" so you hit "Cancel" instead — all CLS. Threshold: under 0.1 is good.

The cause is almost always the same: elements whose size wasn't declared in advance. Images without width and height, ad and banner slots that load late, fonts that arrive after the text. The fix isn't an architectural revolution; it's discipline. Reserve the space first, load the thing second.

Where do you read the report card?

There are two sources, and mixing them up is the most common mistake.

Field data: what real Chrome users actually experienced on your site, collected in Google's CrUX dataset. This is what Google considers for ranking. You'll see it at the top of PageSpeed Insights and in Search Console's Core Web Vitals report. Note: low-traffic sites may have no field data at all — that's not an error, it's an insufficient sample.

Lab data: a one-off measurement run by tools like Lighthouse on a simulated device. Perfect for debugging — but it is not the report card Google reads. "I scored 95 in Lighthouse" feels great; what affects rankings is what real users lived through.

One more subtlety: the assessment is based on the 75th percentile of users. The site opening fast on your office fiber connection proves nothing; the visitor on a phone in a moving train is part of the grade too.

How do bad grades get fixed? In order of payoff

On a typical site, the wins rank roughly like this, largest first:

  1. Tame the images. Modern formats (WebP/AVIF), serving at actual display size, prioritizing above-the-fold images. On most sites this alone is the biggest LCP win available.
  2. Interrogate third-party scripts. Every marketing pixel and chat bubble eats into INP. The question is simple: what did this script earn you last month? No answer, no script.
  3. Speed up the server response. Every hundred milliseconds spent before the page even starts arriving is charged straight to LCP. Caching, better hosting, or a CDN does the work here.
  4. Reserve space. Dimensions on images, fixed heights on ad slots, a loading strategy for fonts. CLS is mostly solved by these three habits.

Patch it with plugins, or fix the architecture?

Let's be honest: on a WordPress site, installing a caching plugin and compressing your images can pull the report card from red to orange, sometimes to green. That is a legitimate path, and often a sufficient one — if the site is well built, you may not need to touch the architecture at all.

But there's a threshold: when optimization plugins start stacking up, breaking each other, and demanding re-tuning after every theme update, you're no longer optimizing speed — you're trying to purchase it, monthly. On statically generated sites, that fight never starts: pages arrive as finished files from a CDN, LCP is naturally low, CLS sits near zero with basic discipline, and INP stays comfortably under threshold because there's little JavaScript to choke on. Speed stops being a feature you add and becomes an output of the architecture.

A realistic expectation: how fast does the grade improve?

Even after your fixes go live, field data doesn't move immediately — CrUX works on a 28-day rolling window. An improvement you ship today takes weeks to fully register on the card. This is the most common explanation for the "we fixed it but nothing happened" panic: it probably did work; the card just hasn't caught up. Watch the trend in Search Console — if the direction is up, you're on the right path.

If you've never seen your own report card, take five minutes and run your site through PageSpeed Insights — after this guide, the report won't read like a foreign language anymore. And if the result is red and plugin patches aren't moving it, the problem is probably architectural, not cosmetic. If you'd like to talk through a case like that, write to Vucod — every inquiry gets a clear answer within 48 hours: vucod.com

Tags:core web vitalswebsite speedseolcppage experience