--- title: Free Core Web Vitals Checker description: Run a full Google Lighthouse audit on any URL and get an A+ to F performance grade against Google's Core Web Vitals thresholds — Largest Contentful Paint, Cumulative Layout Shift, Total Blocking Time and server response time, the loading filmstrip frame-by-frame and the top opportunities to fix, each finding with its fix. 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 get an A+ to F performance grade against Google's Core Web Vitals thresholds — Largest Contentful Paint, Cumulative Layout Shift, Total Blocking Time and server response time, the loading filmstrip frame-by-frame and the top opportunities to fix, each finding with its fix. [How to use this tool](/blog/how-to-check-core-web-vitals) Result No result yet Fill in the form above and run it — the result appears here. Monitor this 24/7 — get alerted when a failure is confirmed. [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). ## The performance grade scale Every run gets one of these grades from Google's published Core Web Vitals thresholds — the same ones for mobile and desktop. A page Lighthouse could not measure gets no grade at all. A+ Fast Every measured Core Web Vital, Total Blocking Time and server response time is in Google's good band, and the Lighthouse performance score is 90 or more. A Good Fast to paint and stable, with a server response time between 0.8 s and 1.8 s. B Needs improvement At least one metric in Google's “needs improvement” band (LCP 2.5–4 s, CLS 0.1–0.25, TBT 200–600 ms), or a performance score of 50–89. C Slow At least one metric in Google's poor band: LCP over 4 s, CLS over 0.25, TBT over 600 ms, or a server response over 1.8 s. D Poor Lighthouse performance score 25–49 — its red band. F Failing A performance score under 25, or the main content takes more than 10 s to appear. ## Every rule, in full A run starts at A+ and each metric outside Google's good band can only lower the ceiling, so the grade is always explained by the worst finding in the report. Interaction to Next Paint needs real visitors, so a lab run grades Total Blocking Time in its place. Rules version cwv-2026.10 . Grade at most When F Lighthouse performance score under 25 F Largest Contentful Paint over 10 s D Lighthouse performance score 25–49 C Largest Contentful Paint over 4 s (poor) C Cumulative Layout Shift over 0.25 (poor) C Total Blocking Time over 600 ms (poor) — the lab stand-in for INP C Interaction to Next Paint over 500 ms (poor), only when a value is reported C Server response time (time to first byte) over 1.8 s (poor) B Lighthouse performance score 50–89 B Largest Contentful Paint over 2.5 s, up to 4 s B Cumulative Layout Shift over 0.1, up to 0.25 B Total Blocking Time over 200 ms, up to 600 ms B Interaction to Next Paint over 200 ms, up to 500 ms, only when reported A Server response time over 0.8 s, up to 1.8 s — A metric Lighthouse did not report (INP in a lab run, server response time on older runs) — noted, never counted — Lighthouse could not measure the page (load failure, no score) — no grade at all Lab data is not field data: the grade covers one simulated page load from one probe location. Google ranks pages on 28 days of field data from real Chrome users (the Chrome UX Report), which can differ from a single lab run in either direction. [How WatchFor grades everything the same way](/grades#core-web-vitals) ## 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. Every run also gets a WatchFor Performance grade from A+ to F, built from Google's own published thresholds. It starts at A+ and each metric outside the good band can only lower the ceiling, so the letter is always explained by the worst finding — listed first, with the exact fix and the run's own biggest opportunity next to it. If Lighthouse could not measure the page, there is no grade at all rather than an unfair F. ## 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 Grade it against Google's thresholds — Each metric is placed in Google's good / needs-improvement / poor band — LCP 2.5s / 4s, CLS 0.1 / 0.25, TBT 200ms / 600ms, server response 0.8s / 1.8s, performance score 90 / 50 — and the worst band sets the grade (rules version cwv-2026.10 , published in full below the tool). - 5 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 grade (A+ to F) The letter at the top. A+ means every measured vital, Total Blocking Time and server response time is in Google's good band with a score of 90+. A metric in the needs-improvement band caps it at B, one in the poor band at C, a performance score under 50 at D, and a score under 25 or an LCP over 10s at F. The findings under it are sorted worst first; fix the first one and the grade moves. ### 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 alerted when an outage is confirmed — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 15 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. How is the performance grade calculated? It starts at A+. Every metric outside Google's good band lowers the ceiling: needs-improvement LCP , CLS or TBT (or a performance score of 50–89) caps it at B, a poor one at C, a slow server response (0.8–1.8s) at A and over 1.8s at C, a score of 25–49 at D, and a score under 25 or LCP over 10s at F. The worst finding wins and nothing adds points back. The full rule table and rules version ( cwv-2026.10 ) are on this page. Why is INP not graded? Interaction to Next Paint measures real visitors' taps and clicks, so a single lab load has nothing to measure. Lighthouse reports Total Blocking Time as the lab stand-in, and the grade uses that (good ≤ 200ms, poor above 600ms). When a run does report INP , it is graded with Google's thresholds (200ms / 500ms). Why can my grade differ from PageSpeed Insights? Both run Google Lighthouse, but from different machines, locations and networks, and lab results move a little between any two runs. PageSpeed Insights also shows field data from the Chrome UX Report when Google has enough real-user traffic for the URL; our grade covers only the lab run, and says so. Treat it as a diagnosis of this load, not a forecast of your field data. 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, shows the same performance grade for its latest audit, 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