Core Web Vitals Checker

How it works

What we check

• Largest Contentful Paint (LCP) — Loading speed — the time until the largest visible element (usually a hero image or headline) finishes rendering. Google's thresholds: good is under 2.5 seconds, 2.5 to 4.0 seconds needs improvement, and over 4.0 seconds is poor.
• Cumulative Layout Shift (CLS) — Visual stability — how much the page jumps around as it loads. It's a unitless score: good is under 0.1, 0.1 to 0.25 needs improvement, and above 0.25 is poor. Caused by images and ads loading without reserved space.
• Interaction to Next Paint (INP) — Responsiveness — how quickly the page reacts to taps, clicks and key presses across a whole visit. Good is under 200 milliseconds, 200 to 500 needs improvement, and over 500 is poor. INP replaced First Input Delay as a Core Web Vital in 2024.
• Overall performance score — A single 0–100 lab score summarizing how fast the page loads in our simulated mobile test. 90 and up is good, 50–89 needs work, and under 50 is poor. It's a useful headline number, but the individual vitals are what Google evaluates.
• Mobile-first measurement — We test on a simulated mobile device because that's how most people browse and how Google primarily assesses pages. Mobile is typically slower than desktop, so it surfaces the problems that matter most to real visitors.
• Top opportunities — The specific, ranked fixes that would most improve your score — oversized images, render-blocking resources, unused code and similar — so you know exactly what to tackle first instead of guessing.

Common issues we catch

• Slow LCP from a heavy hero image — The largest element is often a big, uncompressed banner image loaded late. Serving it in a modern format, sizing it correctly, and preloading it can cut LCP by seconds — usually the single biggest win on a slow page.
• Layout shift from images without dimensions — Images and embeds that don't declare width and height let the browser reflow the page once they load, shoving content down as the user reads. Setting explicit dimensions (or aspect-ratio) reserves the space and stops the shift.
• Poor INP from heavy JavaScript — Too much script running on the main thread blocks the page from responding to taps and clicks, which shows up as a high INP. Breaking up long tasks and deferring non-critical scripts keeps interactions snappy.
• Render-blocking CSS and JavaScript — Stylesheets and scripts loaded in the head before content can render delay LCP. Inlining critical CSS and deferring the rest lets the page paint sooner without waiting on every resource.
• Good lab score but failing field data — A page can score well in a single lab test yet still fail Core Web Vitals, because Google judges by real-visitor field data at the 75th percentile over a 28-day window. A fast test on fast hardware doesn't reflect users on slower phones and networks.
• Layout shift from web fonts — Custom fonts that swap in after a fallback renders can nudge text and cause CLS late in the load — a shift that's easy to miss because it happens after the page looks done. Preloading fonts and using font-display swap with matched fallbacks reduces it.
• Third-party scripts dragging everything down — Chat widgets, analytics, ad and tag-manager scripts run on your page but not under your control. They can spike INP and delay LCP. Auditing what's loaded and removing or deferring the non-essential ones often recovers real performance.

Where this matters

• Google Search — Core Web Vitals are part of Google's page-experience signals. Passing all three at the 75th percentile of real-visitor data is the bar — and a poor experience can hold back pages that would otherwise rank well on relevance.
• Mobile devices — We measure on a simulated mobile device because mobile is how most people browse and the harder case to pass. Fixing mobile vitals usually carries over to desktop, rarely the other way around.
• WordPress, Shopify, Wix & page builders — Themes, plugins and builder bloat are common sources of slow LCP and layout shift. The opportunities we surface point to the specific images, scripts and styles to trim, even when you can't touch raw code.
• Field data vs. lab data — Lab data is a single controlled test (what this tool runs); field data is aggregated real-visitor experience over 28 days. Google judges on field data, so use the lab test to diagnose and fix, then watch field data confirm the gain.
• Single-page apps & JavaScript frameworks — JS-heavy sites are especially prone to high INP and late layout shifts because so much happens after the initial load. The responsiveness and stability metrics catch problems a simple load-time check would miss.