Most "my site is slow" complaints are really one of three specific, measurable problems — and Google has names for them. Core Web Vitals are the three numbers Google uses to score how a real page feels to a real visitor: how fast the main content shows up, how much the layout jumps around while loading, and how quickly the page responds when someone taps or clicks. Get them wrong and you lose visitors and search ranking; get them right and you've fixed the things that actually frustrate people.
The short version: you can't fix what you don't measure, and you should fix them in order of which one is failing. Vague speed work scattered across a site rarely moves the score. Pinpoint the one failing metric on your most important pages, find its specific cause, and fix that — then re-measure.
The three metrics, in plain terms
There are exactly three Core Web Vitals, each with a published "good" threshold. Knowing the threshold matters, because Google grades you against it — a metric is either passing or it isn't.
- Largest Contentful Paint (LCP) — how long until the biggest visible element (usually a hero image, banner, or headline block) finishes loading. Good is 2.5 seconds or less. This is your "how fast does the page feel" metric.
- Cumulative Layout Shift (CLS) — how much the page jumps around as it loads, on a scale from 0 up. You've felt this: you go to tap a button, an image loads above it, the button moves, and you tap the wrong thing. Good is 0.1 or less.
- Interaction to Next Paint (INP) — how quickly the page responds after you interact with it, in milliseconds. Good is 200ms or less. This replaced the older First Input Delay metric in 2024, so older advice that mentions FID is out of date.
A page passes Core Web Vitals only when all three are in the "good" band, measured on real visitors over the trailing 28 days. That last detail trips people up, which is why measurement comes first.
Lab data vs. field data: the trap that wastes the most time
This is the single most common mistake, so it goes near the top. When you test a page, you get two kinds of data, and they often disagree.
- Lab data is a single simulated test run from a tool's own server, on a fixed connection. It's repeatable and great for debugging.
- Field data (also called CrUX, the Chrome User Experience Report) is what your actual visitors experienced — real phones, real networks, real distances. This is what Google ranks on.
Here's the trap: a page can score a beautiful 98 in the lab and still fail Core Web Vitals in the field, because your real visitors are on mid-range phones over patchy mobile data, not on a fast test server. Always read the field data first. If a page has enough traffic, PageSpeed Insights shows it at the top under "Discover what your real users are experiencing." If it says "not enough data," then — and only then — lean on lab data as a proxy. Optimizing for the lab number while the field number fails is how teams burn a week and move nothing.
A worked example: turning a failing page around
Take a real-world pattern. A services business runs PageSpeed Insights on its homepage and sees field data:
- LCP: 4.1s (failing — threshold 2.5s)
- CLS: 0.28 (failing — threshold 0.1)
- INP: 150ms (passing)
Two metrics fail. INP is fine, so leave it alone — touching it would be wasted effort. Now diagnose the two failures specifically.
LCP at 4.1s. The diagnostics flag the largest element as the hero image, a 2.4 MB JPEG served at full camera resolution into a slot that's only 1200px wide. The fix: export it properly sized, compress it, and serve a modern format (WebP or AVIF). That one image drops from 2.4 MB to about 180 KB. LCP falls to 2.2s — now passing. A single oversized hero image is the most common LCP failure there is.
CLS at 0.28. The diagnostics show the shift comes from two sources: the hero image has no width and height set, so the browser doesn't reserve space and everything below it jumps when the image arrives; and a cookie banner injects itself at the top after load, shoving the whole page down. The fix: add explicit width and height attributes (or a CSS aspect-ratio) so the browser reserves the space, and give the cookie banner a fixed, reserved area instead of letting it push content. CLS drops to 0.04 — passing.
Net result: the page went from failing to passing by fixing two concrete things on the one element that was actually causing trouble — not by a vague "make it faster" sweep. That's the pattern: measure, find the specific culprit, fix it, re-measure.
The common causes, by metric
Once you know which metric is failing, the likely causes are short and predictable.
What usually breaks LCP
- Oversized, uncompressed images — by far the most common. Right-size and compress them, and use modern formats.
- Render-blocking resources — heavy CSS and JavaScript that must load before anything paints. Trimming and deferring non-critical scripts helps.
- Slow server or cheap, overloaded hosting — if the server is slow to respond at all (a slow "time to first byte"), nothing downstream can be fast. This is where hosting quality shows up.
- No caching or CDN — every visitor rebuilding the page from scratch, served from one distant location, is slow for anyone far away.
What usually breaks CLS
- Images and videos without dimensions — the browser can't reserve space, so content jumps when media loads.
- Ads, embeds, and banners injected after load — cookie notices, chat widgets, and ad slots that appear and push everything down.
- Web fonts that swap late — text renders in one font, then re-flows when the custom font arrives.
What usually breaks INP
- Heavy JavaScript running on the main thread, so the page can't respond to a tap while it's busy. Third-party scripts (analytics, tag managers, chat tools, tracking pixels) are frequent offenders — every one you add competes for responsiveness.
Edge cases and caveats worth knowing
A few things that aren't obvious until they bite you:
- Mobile and desktop are scored separately. A page can pass on desktop and fail on mobile. Mobile is usually what matters most, since that's where most traffic and the weaker hardware are — always check the mobile tab.
- Field data lags. Because it's a 28-day rolling window, a fix you ship today won't show up in the field score for weeks. Use lab data to confirm the fix worked immediately; wait on the field data for the official verdict. Don't panic that "nothing changed" the next morning.
- Low-traffic pages have no field data at all. If a page doesn't get enough Chrome visitors, there's no CrUX data, and the metric is assessed at the origin (whole-site) level or not at all. Focus measurement on your high-traffic pages.
- Passing Core Web Vitals is not a ranking jackpot. It's one of many signals and acts more like a tie-breaker than a rocket. Fix it because it genuinely improves the visitor experience; treat any ranking lift as a bonus, not a guarantee.
The trick: fix the metric that fails, on the page that matters
If you remember one thing, make it this. Don't chase a perfect score across every page. Open your analytics, find your handful of highest-traffic pages, run each through PageSpeed Insights, and read the field data. For each page, there's usually exactly one metric in the red and exactly one dominant cause behind it. Fix that one thing, confirm it in lab data, and move to the next page. This focused, one-cause-at-a-time approach moves real scores far faster than a broad "speed audit" that touches everything and resolves nothing.
For the deeper context on how performance, hosting, and platform choices fit together, our web development guide covers the decisions that make a site fast and stable in the first place — many Core Web Vitals problems are really platform and hosting decisions catching up with you.
Frequently asked questions
How do I check my Core Web Vitals? Run your page through Google's PageSpeed Insights (free) and read the field data section at the top — that's what Google actually scores. Google Search Console also has a Core Web Vitals report that groups your whole site's URLs into good, needs-improvement, and poor, which is useful for seeing patterns across many pages.
What's the single most common cause of a bad score? Oversized images. A hero or banner image exported at full resolution and never compressed is the most frequent cause of both a slow LCP and, when it has no set dimensions, a high CLS. Properly sizing and compressing images is often the highest-impact fix you can make.
Do Core Web Vitals actually affect my Google ranking? Yes, but modestly. They're a confirmed ranking signal that works as a tie-breaker between pages of similar relevance and quality — not an override that lifts weak content. The stronger reason to fix them is that they measure real frustration that costs you visitors regardless of ranking.
What happened to First Input Delay (FID)? It was replaced by Interaction to Next Paint (INP) in 2024. INP is a stricter, more complete measure of responsiveness across all interactions, not just the first one. If you read older guidance citing FID, it's out of date — optimize for INP instead.
Why didn't my score change after I fixed the problem? Field data uses a 28-day rolling window, so a fix takes weeks to fully reflect. Confirm the fix worked immediately using the lab data in PageSpeed Insights; the field score will catch up over the following weeks.
Bringing it together
Core Web Vitals turn "my site feels slow" into three specific, fixable numbers: LCP for loading, CLS for visual stability, INP for responsiveness. Measure them on real visitors, fix the one metric that's failing on the pages that matter, and verify the fix — that disciplined loop beats any scattered speed effort.
Run one real page through PageSpeed Insights, read the field data, and fix the single metric that's failing before you touch anything else. When you want a site built to pass these checks from the start — or an existing one diagnosed and fixed properly — Top Fully does this work end to end.
