--- title: Free Core Web Vitals Checker description: Run a full Google Lighthouse audit on any URL and see what real users feel — Largest Contentful Paint, Cumulative Layout Shift, Time to Interactive, plus the loading filmstrip frame-by-frame and the top opportunities to fix. The same metrics PageSpeed Insights uses for your search ranking. canonical: https://watchfor.io/core-web-vitals-checker --- [Back to all free tools](/free-tools) # Core Web Vitals Checker Run a full Google Lighthouse audit on any URL and see what real users feel — Largest Contentful Paint, Cumulative Layout Shift, Time to Interactive, plus the loading filmstrip frame-by-frame and the top opportunities to fix. The same metrics PageSpeed Insights uses for your search ranking. Result No result yet Enter the inputs above and press Run. Results appear here in a moment. Monitor this 24/7 — get alerts on the first failure. [Start free](/auth/sign-up) Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our [Terms](/legal/terms). ## What is Core Web Vitals Checker ? Core Web Vitals are the three page-experience metrics Google uses to measure — and rank — how a page *feels* to a real user: Largest Contentful Paint ( LCP , how fast the main content shows up), Cumulative Layout Shift ( CLS , how much the page jumps around while loading), and Interaction to Next Paint / Total Blocking Time ( INP / TBT , how quickly it responds to input). A page can score well on a naive "is it up?" check and still feel slow and janky — and lose search ranking for it. This tool runs a full Google Lighthouse audit on any URL — the same engine behind PageSpeed Insights — from a real headless Chrome. You get the lab Core Web Vitals, an overall performance score, the loading filmstrip frame-by-frame, and the ranked list of opportunities (the specific things costing you milliseconds) — no signup, no Chrome extension, no local setup. ## How it works The audit reproduces what a real browser does on a first visit, then measures every part of it: - 1 Load the page in headless Chrome — A real Chromium instance on a probe loads the URL from scratch — no warm cache, no prior visit — the way a first-time visitor's browser would, over a real network path with throttling applied so the numbers reflect a typical device. - 2 Measure the Core Web Vitals — Lighthouse records LCP , CLS and TBT (the lab proxy for INP ), plus First Contentful Paint and Speed Index — the lab metrics that mirror what Google's field data measures for ranking. - 3 Capture the loading filmstrip — Frame-by-frame screenshots of the page painting in, so you can *see* when the hero content appears and where a layout shift happens — not just read a number. - 4 Rank the opportunities — Every audit that failed or has room to improve is listed with its estimated time saving — render-blocking resources, oversized images, unused JavaScript, missing dimensions causing shift — sorted by impact so you fix the expensive things first. Everything is lab data (a single controlled load), which is perfect for diagnosing *why* a page is slow and confirming a fix — the ranked opportunities are the same ones PageSpeed Insights surfaces. ## When you'd use it ### Before and after a performance fix You lazy-loaded images or split a bundle — did it actually help? Run the audit before and after and compare LCP , TBT and the opportunity list. Lab data is the right tool for a controlled before/after, because it removes the noise of real-user variation. ### A page 'feels slow' but you can't say why The filmstrip and the ranked opportunities turn a vague complaint into a specific cause: a render-blocking font, a giant hero image, a third-party script blocking the main thread. You see the exact frame where it stalls. ### Protecting (or chasing) search ranking Core Web Vitals are a Google ranking signal. If a page slipped in search, its vitals are the first thing to check — and if you're competing for a term, a fast page is table stakes. This is the same metric set Search Console reports on. ### Auditing a competitor or a template Point it at any public URL — a competitor's landing page, a theme you're considering, a marketing page a vendor built — and see its real performance profile before you benchmark against it or buy it. ## Reading the result ### Performance score A 0–100 roll-up of the weighted metrics. 90+ is good, 50–89 needs work, under 50 is poor. It's a useful headline, but the individual vitals tell you what to fix — a single bad metric can sink the score. ### LCP — Largest Contentful Paint When the biggest above-the-fold element (usually the hero image or headline) finishes rendering. Good is ≤ 2.5s. High LCP almost always traces to a slow server response, render-blocking resources, or an unoptimised hero image. ### CLS — Cumulative Layout Shift How much visible content jumps while loading, scored 0–1. Good is ≤ 0.1. The usual causes are images and ads without reserved dimensions, and web fonts swapping in — all visible in the filmstrip. ### TBT / INP — responsiveness Total Blocking Time measures how long the main thread was blocked and can't respond to input — the lab stand-in for field INP . High TBT means too much JavaScript executing during load; the opportunities list points at the scripts responsible. ### Opportunities & filmstrip The ranked fixes with estimated savings, and the frame-by-frame render. Start at the top of the opportunities list — the estimates are cumulative, so the first item is where a real second is hiding. ## Common pitfalls ### Confusing lab data with field data This is a single controlled load (lab data) — ideal for diagnosis and before/after. Google ranks on *field* data (real users, over 28 days) in the Chrome UX Report. A page can pass in the lab and still fail in the field if real users are on slower devices; use the lab to *fix*, the field to *confirm at scale*. ### Chasing the score instead of the metric The 0–100 number is a weighted blend and can swing between runs. Optimise the specific failing vital ( LCP , CLS , TBT ), not the composite — moving the metric is what moves real user experience and ranking. ### Testing only the homepage Your homepage is often the most-optimised page on the site. The pages that actually earn search traffic — articles, product pages, landing pages — are frequently heavier. Audit the templates users land on, not just the front door. ### A one-off run isn't a safety net Performance regresses quietly — a new hero image, a third-party tag, an un-split bundle. A single audit tells you today's number; catching the regression that lands next week needs the check to run continuously. ## Run Core Web Vitals Checker on every change, not just once. Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card. [Start free](/auth/sign-up) ## Frequently asked questions What is a Core Web Vitals checker? A tool that runs a Google Lighthouse audit on a URL and reports the page-experience metrics Google ranks on — Largest Contentful Paint, Cumulative Layout Shift and responsiveness ( TBT / INP ) — plus an overall performance score, a loading filmstrip and a ranked list of what to fix. Is it the same as Google PageSpeed Insights? It uses the same engine — Google Lighthouse — for the lab audit, so the metrics and opportunities line up. PageSpeed also blends in field data from the Chrome UX Report when it's available; this tool focuses on the lab run, which is what you use to diagnose and verify fixes. Is it free? Do I need to install anything? It's free, needs no signup and nothing to install — no Chrome extension, no local Lighthouse. The audit runs in a real headless Chrome on our infrastructure and returns the full report in your browser. What's a good Core Web Vitals score? LCP ≤ 2.5s, CLS ≤ 0.1, and INP ≤ 200ms (lab TBT ≤ 200ms as its proxy) are the "good" thresholds. An overall performance score of 90+ is good, 50–89 needs work, and under 50 is poor. Why is my score different each time I run it? Lab audits vary a little run-to-run — network jitter, server load and third-party scripts all move the number. Focus on the individual metrics and the opportunities, run it a couple of times for a trend, and use before/after comparisons rather than a single absolute number. Can I monitor Core Web Vitals continuously instead of testing once? Yes. A WatchFor browser monitor runs a Lighthouse audit on a schedule from locations worldwide, charts LCP / CLS / TBT over time, and alerts you when a metric crosses your threshold — so a performance regression pages you the day it ships, not when rankings drop. --- Canonical page: https://watchfor.io/core-web-vitals-checker · Site guide: https://watchfor.io/llms.txt