Core Web Vitals & Page Speed: The Complete Guide
Core Web Vitals are the three specific, field-measured metrics Google uses to score real-world page experience — Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability). This guide covers what each one actually measures, the exact thresholds that separate "good" from "poor," why your lab score and your Search Console report can disagree, and which fixes move each metric the most instead of just generically "optimizing" the page.
The three metrics and their exact thresholds
All three, and their exact good/needs-improvement/poor thresholds, are measured at the 75th percentile of real visits to a page or origin — meaning at least 75% of real visits need to hit "good" for the page to pass overall, not just the average visit. That percentile choice matters: a page can look fine on average while still failing Core Web Vitals because its slower quarter of visits (often mobile, on weaker connections) drags the 75th-percentile figure into "needs improvement" or "poor."
- LCP (Largest Contentful Paint) — time until the largest visible element (usually a hero image, a large block of text, or a video poster) finishes rendering. Good: ≤2.5s. Needs improvement: ≤4s. Poor: >4s.
- INP (Interaction to Next Paint) — the latency of the slowest (or near-slowest) interaction across the entire page visit, from input to the next visual update. Good: ≤200ms. Needs improvement: ≤500ms. Poor: >500ms.
- CLS (Cumulative Layout Shift) — a unitless score summing how much visible content unexpectedly moves during the page's lifespan. Good: ≤0.1. Needs improvement: ≤0.25. Poor: >0.25.
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Largest element render time | ≤2.5s | ≤4s | >4s |
| INP | Slowest interaction latency | ≤200ms | ≤500ms | >500ms |
| CLS | Unexpected layout movement | ≤0.1 | ≤0.25 | >0.25 |
Why your PageSpeed Insights score and your Search Console report disagree
This causes more confusion than any other part of Core Web Vitals, and the reason is simple once it's named: they measure two different things.
- Lab data (Lighthouse, PageSpeed Insights' top section) — a single simulated page load under fixed, controlled conditions (a specific throttled connection and CPU profile). Great for debugging a specific fix in isolation and getting consistent, repeatable numbers; not representative of what any real visitor actually experiences.
- Field data (CrUX — Chrome User Experience Report, what powers Search Console's Core Web Vitals report and PageSpeed Insights' lower section) — real, anonymized measurements aggregated from actual Chrome users who visited the page, over a rolling 28-day window.
A page can score perfectly in the lab and still fail in the field, because the lab test doesn't know your real visitors are disproportionately on older phones, slower connections, or with heavy browser extensions installed. Search Console's field report is what Google actually uses for the page-experience signal — treat lab tools as your debugging instrument, and field data as the scorecard.
LCP: what actually moves it
LCP is capped by whichever is slowest in the chain: server response time, render-blocking resources, and the LCP element's own load time. In practice, the highest-leverage fixes are:
- Preload the LCP resource.
<link rel="preload" as="image" href="/hero.jpg">tells the browser to start fetching it immediately, instead of discovering it only after parsing the rest of the HTML. - Fix server response time (TTFB) first. Every other LCP optimization is capped by how fast the HTML document itself arrives — a slow TTFB puts a hard floor under LCP no matter what else is fixed.
- Remove render-blocking CSS/JS above the fold by inlining critical CSS and deferring the rest.
- Don't inline the LCP image as Base64. A Data URI makes the image about 33% larger and buries it inside the HTML or a render-blocking stylesheet, so it can't be preloaded, cached or served responsively. Inlining only pays off for icons of a few kilobytes; the image to Base64 converter shows the encoded size before you decide.
- Serve modern image formats (WebP/AVIF) — smaller file sizes at equivalent visual quality directly cut download time for the LCP element itself.
INP: what actually moves it
INP failures almost always trace back to long tasks blocking the browser's main thread at the exact moment a user tries to interact:
- Break up long JavaScript tasks. Any task over 50ms blocks input processing — split large tasks with
setTimeout,scheduler.yield(), or move genuinely heavy work to a Web Worker off the main thread entirely. - Audit third-party scripts. Ad tags, chat widgets and analytics snippets frequently run unrelated JavaScript on the main thread at unpredictable times — often the actual cause when a page's own code looks lean but INP still fails.
- Debounce expensive input handlers — search-as-you-type and scroll/resize handlers that run heavy logic on every single event compound fast under real, high-frequency usage.
CLS: what actually moves it
CLS is almost always one of two root causes: missing dimensions, or late-inserted content.
- Set width/height or aspect-ratio on every image, video, ad slot and embed. Without a reserved size, the browser can't allocate space before the resource loads, so everything below it visibly jumps once it does.
- Choose font-display and preload web fonts deliberately. A font swap that changes text size or line spacing mid-load is one of the least-noticed, most common causes of CLS — because it happens fast and doesn't look like a bug in casual browsing.
- Never insert new content above what's already rendered without reserving space for it first — a cookie banner or promo bar added dynamically pushes everything below it down.
Frost Rank's own QR Code Generator hit this exact class of bug during development — a canvas with no reserved size caused a measurable layout shift once its real pixel dimensions were set by JavaScript, fixed by setting matching width/height attributes plus a CSS aspect-ratio up front.
Turning this into an actual workflow
The order that works: check Search Console's Core Web Vitals report to see which metric is actually failing in the field (not a guess), fix the highest-impact items for that specific metric, confirm the fix with a lab tool immediately, then wait for the 28-day field window to catch up before declaring victory. Frost Rank's own Page Speed Checklist is built exactly around this — every item is tagged by metric and impact level so the next fix is always obvious instead of a guess, and a slow server response time (the first LCP item above) is exactly what the HTTP Header Checker helps diagnose on a live URL.
Frequently asked questions
At the 75th percentile of real visits, LCP is good at 2.5 seconds or less, INP at 200ms or less and CLS at 0.1 or less. See the full threshold table.
It's one of hundreds of signals in Google's page experience system, and Google has said content relevance still dominates — a page with poor Core Web Vitals but excellent, relevant content will typically still outrank a fast page with weak content for the same query. The realistic case for fixing it is user experience and conversion rate, which are large effects in their own right, with ranking as a secondary benefit mainly in close competitive calls.
The PageSpeed Insights score is a single simulated lab test, while Search Console reports field data from real Chrome users over 28 days, so a page can pass one and fail the other. See lab and field data compared.
INP (Interaction to Next Paint) officially replaced FID as the third Core Web Vital in March 2024. FID only measured the delay before the browser could start processing the very first interaction on a page — it said nothing about responsiveness afterward. INP measures the full click-to-next-paint latency across every interaction during the page's lifespan, which is why a page can have passed FID under the old system and still fail INP now.
Because CrUX field data uses a rolling 28-day window, a fix shipped today only fully replaces the old data after about 28 days — you'll see gradual improvement as the window rolls forward, not an instant jump. Lab tools like Lighthouse or PageSpeed Insights confirm a fix worked immediately; Search Console's field report is what eventually reflects it for ranking purposes.
Google evaluates and reports them separately for mobile and desktop, and real scores commonly differ significantly between the two — mobile is usually the harder target because of slower typical connections and less powerful hardware. Fixing one doesn't guarantee the other passes; check and address them independently.
Reflects INP as the current third Core Web Vital (replacing FID in March 2024), not outdated advice still circulating from before that change — including the exact canvas-sizing CLS bug fixed on Frost Rank's own QR Code Generator, described above.
Was this guide helpful?
Rate it and leave a comment — takes 10 seconds, and genuinely helps decide what to fix or build next.