Checkers

Core Web Vitals Checker

Measured for real, plus the page-weight causes behind the numbers

Core Web Vitals are wall-clock measurements, so they need a real browser actually loading your page. The audit runs in a real headless browser and returns Largest Contentful Paint, Cumulative Layout Shift and Total Blocking Time - the same measurements PageSpeed Insights reports.

Try:

Free, no signupNo account, no card
No AI in the score986 deterministic rules
Nothing publishedYour scans stay yours
Answers in secondsQuick scan, no browser

A metric on its own is not actionable, so 100 further rules cover the causes: render-blocking scripts and stylesheets, caching headers, image sizing and formats, font loading, preconnect and preload hints, and total page weight.

One caveat worth stating plainly: lab measurements vary with the machine that took them. These are directionally right and good for comparing before and after your own changes; for the numbers Google actually ranks on, use field data from the Chrome UX Report.

Why this matters

Everyone says it's slow. It's fast on my machine.

You built the page on a fast machine, on your own connection, with every file already cached. Your customers open it on a phone, on a patchy signal, with nothing cached. They get a white screen, or a layout that jumps under their thumb. The gap between those two experiences is invisible until someone measures it, and a single score for the whole page still does not say which part to change.

What it costs you when this is wrong

Visitors leave before anything paints
A slow Largest Contentful Paint is a white screen while someone decides whether to wait. It rarely arrives as a complaint. You see it as mobile sessions that land and never reach a second page, and as Google's Core Web Vitals report marking URL groups Poor from a rolling window of real-user data, weeks after the change that caused it.
Fingers land on the wrong thing
Images, banners and embeds that reserve no space push the page down as they load. Someone reaching for Add to basket taps the advert that appeared under their thumb a moment earlier. That reaches you as a support email or an abandoned basket, never as a bug report.
The page looks ready and does nothing
Scripts can hold the main thread long after the page has painted, so taps and keystrokes queue with no feedback. People press submit twice. You find it later in duplicate orders, and in form fields that swallowed the first few characters someone typed.

Why run it here

The timed run gets a browser to itself
The timing run is given its own browser and takes its turn alone, because it clears the cache for every tab at once and would corrupt any scan measuring beside it, and because two timing runs side by side measure CPU contention rather than the page. Nothing is dropped to achieve that: a scan queues for a slot and still gets a full run.
69 of the 100 rules never move
31 of the performance rules come from the timed run. The other 69 read the markup and the response headers instead of the clock: compression, cache-control, DOM element count, nesting depth, third-party stylesheets, document.write, tracking pixels. They return the same answer on every scan, so they are still worth acting on when the timings wobble.
Performance is not audited on its own
The same pass reports the other 886 rules against the same URL, in the same report: HTML and CSS conformance, structured data, accessibility, security headers, crawler access and trust signals. Google's PageSpeed Insights covers its own categories, and does not report markup conformance errors or structured-data validity.

This check runs on its own here, and as part of the full audit alongside the other 985 rules. Either way the findings carry their evidence and their citation, and the report is never published or kept.

How to improve Core Web Vitals

Each metric has a dominant cause. Fixing that cause moves the number far more than a long list of micro-optimisations.

For LCP, find the largest element above the fold and make it load sooner — preload the image, serve it in a modern format, and never lazy-load it.
For CLS, set explicit width and height on every image and video, and reserve space for anything injected after load, especially ads and banners.
For INP, break up long JavaScript tasks and defer anything not needed for the first interaction.
Compress and correctly size images. This is usually the single largest saving available on a real site.
Remove unused CSS and JavaScript, and load third-party scripts asynchronously so they cannot block rendering.

What happens when you run it

Enter your address
Just the domain is enough — example.com, with or without the https. No account, no card, no crawl of your whole site.
We render it like a visitor
Your page opens in a real browser and JavaScript runs to completion, so what gets audited is the page a person actually sees — not the raw HTML your server sent. A screenshot comes back with the report as evidence of exactly what we measured.
You get findings you can act on
Up to 986 checks run against that rendered page. Each finding names the rule, quotes the evidence found on your page, cites the public specification behind it, and says what to change. Nothing is a judgement call — run it twice on an unchanged page and the score is identical.

What runs this check

Core Web Vitals measurement
Real browser rendering

Named because provenance is the product. Every finding in your report says which of these produced it, so you can check the reasoning rather than take a score on faith.

Questions

Are these the same numbers Google uses for ranking?: No. Google ranks on field data - real Chrome users, aggregated in CrUX. These are lab measurements from a controlled load, which is what makes them repeatable and useful for testing a change. They are a proxy, and an honest one only if the difference is stated.
Why did my score change between two scans?: Lab performance measurement is sensitive to CPU contention on the machine running it. The deterministic rules around it - render-blocking resources, caching, page weight - do not move, which is why they are reported alongside the metrics rather than instead of them.

Also checks

This page answers these searches too — they are the same job, so they share one page rather than being split across near-identical ones:

core web vitals test
the performance audit test
page speed checker
lcp cls checker

Other checkers

Run the core web vitals checker now

No signup, no credit card. Quick answers in seconds; a full audit takes about a minute.

Run a free scan

No signup. No credit card. Nothing stored but the result.

Core Web Vitals Checker

Measured for real, plus the page-weight causes behind the numbers

Everyone says it's slow. It's fast on my machine.

What it costs you when this is wrong

Visitors leave before anything paints

A slow Largest Contentful Paint is a white screen while someone decides whether to wait. It rarely arrives as a complaint. You see it as mobile sessions that land and never reach a second page, and as Google's Core Web Vitals report marking URL groups Poor from a rolling window of real-user data, weeks after the change that caused it.

Fingers land on the wrong thing

Images, banners and embeds that reserve no space push the page down as they load. Someone reaching for Add to basket taps the advert that appeared under their thumb a moment earlier. That reaches you as a support email or an abandoned basket, never as a bug report.

The page looks ready and does nothing

Scripts can hold the main thread long after the page has painted, so taps and keystrokes queue with no feedback. People press submit twice. You find it later in duplicate orders, and in form fields that swallowed the first few characters someone typed.

Why run it here

The timed run gets a browser to itself

The timing run is given its own browser and takes its turn alone, because it clears the cache for every tab at once and would corrupt any scan measuring beside it, and because two timing runs side by side measure CPU contention rather than the page. Nothing is dropped to achieve that: a scan queues for a slot and still gets a full run.

69 of the 100 rules never move

31 of the performance rules come from the timed run. The other 69 read the markup and the response headers instead of the clock: compression, cache-control, DOM element count, nesting depth, third-party stylesheets, document.write, tracking pixels. They return the same answer on every scan, so they are still worth acting on when the timings wobble.

Performance is not audited on its own

The same pass reports the other 886 rules against the same URL, in the same report: HTML and CSS conformance, structured data, accessibility, security headers, crawler access and trust signals. Google's PageSpeed Insights covers its own categories, and does not report markup conformance errors or structured-data validity.

Questions

Are these the same numbers Google uses for ranking?

No. Google ranks on field data - real Chrome users, aggregated in CrUX. These are lab measurements from a controlled load, which is what makes them repeatable and useful for testing a change. They are a proxy, and an honest one only if the difference is stated.

Why did my score change between two scans?

Lab performance measurement is sensitive to CPU contention on the machine running it. The deterministic rules around it - render-blocking resources, caching, page weight - do not move, which is why they are reported alongside the metrics rather than instead of them.

Core Web Vitals Checker

Everyone says it's slow. It's fast on my machine.

What it costs you when this is wrong

Visitors leave before anything paints

Fingers land on the wrong thing

The page looks ready and does nothing

Why run it here

The timed run gets a browser to itself

69 of the 100 rules never move

Performance is not audited on its own

How to improve Core Web Vitals

What happens when you run it

Enter your address

We render it like a visitor

You get findings you can act on

What runs this check

Questions

Also checks

Other checkers

Run the core web vitals checker now

Core Web Vitals Checker

Everyone says it's slow. It's fast on my machine.

What it costs you when this is wrong

Visitors leave before anything paints

Fingers land on the wrong thing

The page looks ready and does nothing

Why run it here

The timed run gets a browser to itself

69 of the 100 rules never move

Performance is not audited on its own

How to improve Core Web Vitals

What happens when you run it

Enter your address

We render it like a visitor

You get findings you can act on

What runs this check

Questions

Also checks

Other checkers

Run the core web vitals checker now