Grade your Core Web Vitalsagainst Google's own line.
Google publishes the exact thresholds it uses to call a page fast or slow — most tools bury them. Paste your LCP, INP, and CLS and this grader rates each one good, needs-improvement, or poor against those numbers, then tells you the one thing that matters: do all three pass, or not.
Your metrics
Largest Contentful Paint. Good is ≤ 2.5s.
Interaction to Next Paint. Good is ≤ 200ms.
Cumulative Layout Shift. Good is ≤ 0.1.
Use your field (real-user) numbers from PageSpeed Insights or the Chrome UX Report — that's what Google grades, not the lab score.
The grade
Vitals score
Metric by metric
LCP · Needs improvement
2.8s — Needs improvement. Good is ≤ 2.5s; needs-improvement up to ≤ 4s; poor is > 4s.
INP · Needs improvement
220ms — Needs improvement. Good is ≤ 200ms; needs-improvement up to ≤ 500ms; poor is > 500ms.
CLS · Needs improvement
0.12 — Needs improvement. Good is ≤ 0.1; needs-improvement up to ≤ 0.25; poor is > 0.25.
Where each Vital sits vs. Google's line
LCP — Largest Contentful Paint
2.8s · target ≤ 2.5s
INP — Interaction to Next Paint
220ms · target ≤ 200ms
CLS — Cumulative Layout Shift
0.12 · target ≤ 0.1
Lower is better on every Vital. The amber tick is Google's good ceiling; the green band is a pass, the red band is poor, and the gap between them is needs-improvement. A page only passes when all three markers land inside the green.
Your move
Your Vitals tell you what's slow. I find out why it's costing you.
3 of 3 Vitals aren't in the good band yet — that's a failing page experience score.
A failing Vital is rarely just a speed problem — it's lost conversions and lost rankings you can actually price. Send me the page that's struggling and I'll walk you through which metric to fix first, what it's worth, and the order of operations to get to a pass. Free, and yours to keep either way.
Plain English
Three numbers Google watches. One verdict you live with.
Core Web Vitals are the three field metrics Google uses to score real-world page experience. LCP (Largest Contentful Paint) measures loading — how long until the biggest thing in the viewport is on screen. INP (Interaction to Next Paint) measures responsiveness — how quickly the page reacts when someone taps, clicks, or types. CLS (Cumulative Layout Shift) measures visual stability — how much the layout jumps around while it loads.
In March 2024, INP replaced FID (First Input Delay) as the official responsiveness Vital. FID only timed the first interaction's input delay; INP watches the slowest interaction across the whole visit and counts the full time to the next paint, so it's a far harder, more honest test. If you're still optimizing for FID, you're optimizing for a metric Google retired.
A page 'passes' Core Web Vitals only when all three are in the good band — at the 75th percentile of real visits. One metric in the poor band fails the whole page. This grader takes your three numbers and applies Google's exact thresholds to each, so you know precisely which Vital is dragging you down and how far it has to move.
The formula
Pass = LCP ≤ 2.5s AND INP ≤ 200ms AND CLS ≤ 0.1 (all three in the good band)
LCP 2.8s (needs-improvement), INP 220ms (needs-improvement), CLS 0.12 (needs-improvement) → the page fails. None are in the poor band, but none are good either, so Google does not award a pass. Get LCP under 2.5s, INP under 200ms, and CLS under 0.1 and the verdict flips.
Google's exact thresholds
These are the cut-offs Google applies at the 75th percentile of real visits. Good is a pass; needs-improvement and poor are not. Lower is better on every one:
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP — Largest Contentful Paint | ≤ 2.5s | ≤ 4s | > 4s |
| INP — Interaction to Next Paint | ≤ 200ms | ≤ 500ms | > 500ms |
| CLS — Cumulative Layout Shift | ≤ 0.1 | ≤ 0.25 | > 0.25 |
Source: Google web.dev — Core Web Vitals · 2024
A Vital came back red. Here's where to look.
LCP is slow.
The largest element (usually the hero image or H1) is taking too long to paint. Compress and preload that one asset, serve it in a modern format, cut render-blocking CSS/JS, and put a real CDN in front of it. LCP responds fastest to fixing the single biggest element, not the whole page.
INP is slow.
Your main thread is busy when people interact. Break up long JavaScript tasks, defer or remove third-party scripts (chat widgets, tag managers, A/B tools are the usual culprits), and stop hydrating things the user can't see. INP is a JavaScript problem far more than a network one.
CLS is high.
Things move after they render. Set explicit width/height (or aspect-ratio) on images and embeds, reserve space for ads and late-loading banners, and never inject content above existing content. CLS is the cheapest Vital to fix and the one users hate the most.
All three are borderline.
You don't have a Vitals problem, you have a weight problem. The page is shipping too much — too many scripts, too much unoptimized media, too little caching. Cut the payload and all three move together. Start with the heaviest third-party tags.
How to move every Vital in the right direction
01Preload the LCP image
Find the largest above-the-fold element and preload it with high fetch priority. One tag often takes a full second off LCP.
02Serve next-gen formats
AVIF or WebP at responsive sizes cuts image weight by half or more — the single biggest lever on LCP for image-led pages.
03Kill render-blocking resources
Inline critical CSS, defer the rest, and load non-critical JS with defer/async so the browser can paint sooner.
04Break up long tasks
Any script task over 50ms blocks interaction. Split work, yield to the main thread, and lazy-load below-the-fold logic to protect INP.
05Audit third-party scripts
Each chat, analytics, and A/B tag taxes INP. Remove what you don't need; load the rest after interaction or via a web worker.
06Reserve space for media
Set width and height (or aspect-ratio) on every image, iframe, and ad slot so nothing reflows. This alone usually clears CLS.
07Avoid late content injection
Cookie bars, promo banners, and lazy fonts that push the page down all spike CLS. Reserve their space or render them outside the flow.
08Cache and use a CDN
Edge caching and proper TTLs shorten time-to-first-byte, which sits underneath LCP for every returning and global visitor.
09Measure field, not just lab
Optimize against CrUX / real-user data — Lighthouse lab scores can look great while real visits fail at the 75th percentile.
10Fix the 75th percentile
Your median can pass while real users fail. Chase the slow tail (older phones, weak networks); that's the number Google grades.
The vocabulary
- LCP
- Largest Contentful Paint: time until the biggest element in the viewport renders. Good ≤ 2.5s. Measures loading speed.
- INP
- Interaction to Next Paint: the slowest interaction-to-paint time across a visit. Good ≤ 200ms. Replaced FID in March 2024.
- CLS
- Cumulative Layout Shift: how much visible content unexpectedly moves while loading. Good ≤ 0.1. Unitless score.
- 75th percentile
- The threshold Google grades at: 75% of real visits must meet the good bar for the page to pass that metric.
- Field data (CrUX)
- Real-user measurements from the Chrome User Experience Report — what Google actually scores you on.
- Lab data
- Synthetic measurements from a tool like Lighthouse in a controlled environment. Useful for debugging, not for the verdict.
Core Web Vitals questions, straight answers
LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1 — all measured at the 75th percentile of real visits. Hit all three and your page passes. Miss any one and it doesn't, even if the other two are excellent.
Keep going
A calculator tells you what. A call tells you what to do about it.
Send me the account behind these numbers. I'll tell you straight where the money's leaking and what I'd fix first — free, and you keep it whether you hire me or not.