Test LCP, INP, and CLS for any URL. Get the same Lighthouse-grade scores Google uses to rank your pages.
Core Web Vitals are the three metrics Google uses to decide whether your page delivers a good user experience: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). This free checker runs the exact same Lighthouse audit Google's own search team uses, against a real Chromium instance, and returns a score plus the specific opportunities that are dragging it down.
## What 'passing' actually means
Google's threshold for a passing page is LCP under 2.5 seconds at the 75th percentile of visits, INP under 200 milliseconds, and CLS under 0.1. The 75th-percentile rule matters: an average that looks great can hide a long tail of slow loads on cheap Android phones over flaky 4G. We surface both the lab number (this single run) and explain how it differs from the field data Google uses for ranking.
## LCP — Largest Contentful Paint
LCP is the time from navigation start until the largest above-the-fold element finishes painting. For most pages that element is the hero image, a video poster, or a block of headline text. The most common LCP killers are uncompressed hero images, render-blocking CSS in the `<head>`, and slow time to first byte from origin servers. Preloading the LCP image with `<link rel="preload" as="image">` and serving it from a CDN at the right intrinsic size usually shaves 1–2 seconds in one change.
## INP — Interaction to Next Paint
INP replaced First Input Delay in March 2024 because FID only measured the first click on the page. INP measures the latency of every interaction and reports the worst (P98). It catches frameworks that do too much synchronous work on click — React state updates that re-render a 5,000-node tree, third-party tag managers that fire on every tap, expensive event handlers attached to the document. The fix is usually breaking work into smaller tasks with `scheduler.yield()` or `requestIdleCallback`, and removing event listeners that don't earn their keep.
## CLS — Cumulative Layout Shift
CLS measures how much content jumps around after first paint. The villains are images without dimensions, web fonts that swap and reflow text, late-loading ad slots, and cookie banners that push the page down. Every shift is unsigned and weighted by impact area, so a banner shifting the entire viewport is far worse than a small avatar swapping in. Setting explicit `width` and `height` on every image and reserving space for embeds takes CLS from terrible to near-zero in an afternoon.
## How this tool fits into ongoing monitoring
One-shot tests catch the obvious regressions. Real ranking requires watching CrUX field data weekly and getting paged the moment a deploy breaks LCP. Lemwatch tracks Core Web Vitals on a schedule, alerts on regressions, and pulls in CrUX so you see what Google actually sees — not just what your laptop on office WiFi sees.
## Lab data vs field data — why both exist
Every CWV conversation eventually hits the lab-vs-field distinction. Lab data is what this tool returns: one synthetic run on a known device profile under known network conditions. It's reproducible, fast, and great for catching regressions before they ship. Field data — what Google uses to rank — is collected from real Chrome users over the last 28 days via the Chrome User Experience Report (CrUX), reported at the 75th percentile, and only available for sites with enough Chrome traffic. Lab tells you whether the page CAN pass; field tells you whether it DOES pass for real users. Both matter. A page that passes in the lab but fails in the field usually has a long tail of slow-network or low-end-device users the lab profile doesn't represent. The fix is the same (optimise the page); the diagnostic is different.
## Stack-specific fix patterns
Most CWV failures fall into predictable buckets by stack:
- **WordPress** — page builders (Elementor, Divi) ship 200–500KB of CSS even on pages that don't use 90% of it. Use a critical-CSS plugin, switch to a leaner builder, or bite the bullet and use Gutenberg. The other killer is unoptimised hero images uploaded straight from a phone camera — install an image-CDN plugin. - **Shopify** — third-party apps inject scripts on every page. Audit the app drawer ruthlessly; every app you don't use is INP debt. Also: enable native lazy-loading on product images, which Shopify still defaults to off in some themes. - **React SPA / Next.js** — hydration is the INP enemy. Migrate marketing pages to Server Components or static export. Defer client-only JS with `dynamic()` and `ssr: false` only when you really need it. - **Vue / Nuxt** — same hydration story as React. Nuxt 3's `<ClientOnly>` is great for non-critical widgets; abuse it for analytics. - **Headless commerce (Sanity + Next, Shopify Hydrogen, etc.)** — your CWV ceiling is your image CDN's resize speed. Pick a CDN with on-the-fly AVIF support; serve the LCP image as a `<link rel="preload" imagesrcset>` from the edge.
## The hidden cost of failing CWV
CWV is not just a ranking factor. Internal data from Google shows that improving LCP by 0.5 seconds increases conversion rates by 5–15% across e-commerce. INP improvements above 200ms drop bounce by similar amounts. The ranking lift is the smaller half of the value — the conversion-rate lift is the larger half. Treat CWV as a revenue project, not an SEO project, and the business case writes itself.
## The most common single-line fix
If you ran this audit and your LCP is bad and you only have time to ship one fix, here it is: add `fetchpriority="high"` to your hero `<img>` and `loading="eager"`. For most pages that one attribute pair improves LCP by 200–600ms because it tells the browser to fetch that image before scripts and stylesheets. It's a 90-second change and we've never seen it not help.
Core Web Vitals are confirmed Google ranking signals. Pages that fail any one of LCP, INP, or CLS rank lower, lose featured-snippet eligibility, and convert worse — every 100ms of LCP costs measurable conversion rate.
We launch a headless Chromium instance through the Lighthouse Node API and load the URL with the mobile preset (Moto G4 emulation, 4G throttling, 4× CPU slowdown). The result is the lab profile Google uses for its CWV report. We capture the canonical metrics — LCP, INP, CLS, FCP, TTFB, TBT, SI — alongside the audit list so we can show you which specific element triggered the LCP timer or which long task spoiled INP. The single-run lab number is intentionally pessimistic versus your CrUX field data; we use the conservative number so passing here usually means passing in the wild. Each run takes 12–25 seconds depending on origin response time. No client-side measurements are taken — your visitors' devices are never instrumented by this tool.
Google treats a page as passing when LCP is under 2.5 seconds, INP is under 200 milliseconds and CLS is below 0.1, measured at the 75th percentile of real visits. Lab numbers on this page tell you whether you are close; field data decides.
They're lab scores from the same Lighthouse engine Google uses internally. The field scores Google uses for ranking come from CrUX (Chrome User Experience Report) data collected over 28 days from real Chrome users. Lab and field rarely match exactly, but if you're failing in the lab you will fail in the field.
LCP under 2.5s, INP under 200ms, CLS under 0.1 — all measured at the 75th percentile. Anything in the "needs improvement" or "poor" band loses ranking weight and can disable rich-results eligibility.
PSI shows both lab and field. Our tool shows lab only because field data needs 28 days of real traffic. The lab score should be within 10–20% of the PSI lab score for the same URL.
Mobile. Google uses mobile-first indexing — your mobile CWV is what ranks. We test mobile by default; desktop scores are almost always 1.5–2× better and are not what gets ranked.
After every significant deploy and weekly otherwise. The number-one cause of broken CWV is a third-party script someone added without telling the perf team. Continuous monitoring catches this in minutes instead of weeks.
INP (Interaction to Next Paint) measures the latency of every interaction on the page and reports the worst at the 98th percentile. FID only measured the first input, which let pages with one fast click but many slow ones pass. Google made the switch in March 2024 because INP correlates much better with actual user-perceived responsiveness.
You don't need to — CrUX only collects from real Chrome users who have opted in to anonymous usage statistics. Bots and headless Chromium runs are excluded by definition.
Google treats a page as passing when LCP is under 2.5 seconds, INP is under 200 milliseconds and CLS is below 0.1, measured at the 75th percentile of real visits. Lab numbers on this page tell you whether you are close; field data decides.