Core Web Vitals Test — Free Website Speed Test

What Core Web Vitals are, and why these three

For years, "page speed" was a number nobody could agree on. One person measured when the server replied, another when the spinner in the browser tab stopped, a third when the last tracking pixel finished. None of those described what a human being in front of the screen actually experienced.

Core Web Vitals start from the opposite end. Google picked three questions that matter from a visitor's point of view: Can I see something yet? Does it stay where it is? Does it respond when I tap it? Those became LCP, CLS and INP. They were deliberately chosen so they can be measured on real users in the wild, not only in a lab.

They have been part of Google's page experience signals since 2021. In March 2024, INP replaced the older FID metric. The thresholds have not moved since, and that is no accident: Google set them so that a well-built site can realistically hit them without the bar being meaningless.

One detail that gets missed a lot: Google does not judge the average, it judges the 75th percentile of your visitors. A page only counts as good when three out of four loads come in under the threshold. That strictness is deliberate — an average would quietly hide the slow half of your audience, and the slow half is exactly who leaves.

LCP — when the main content finally arrives

Largest Contentful Paint records when the biggest visible element in the initial viewport has finished painting. In practice that is nearly always a hero image, a product photo, or on text-heavy pages the large heading block. The logic is disarmingly simple: once the largest element is there, a person considers the page loaded — even if thirty requests are still in flight behind the scenes.

LCP breaks into four phases, and knowing which one eats your time is half the fix:

• Time to first byte: how long before the server says anything at all?
• Load delay: how much time passes between the first byte and the browser actually requesting the LCP element?
• Load duration: how long does transferring that resource take?
• Render delay: how long between the download finishing and the pixels appearing?

The usual causes of a poor LCP

Huge, unoptimised images. This is by far the most common one. A hero image straight from a camera at 3,000 pixels wide and 2 MB, scaled down to 800 pixels by CSS, is pure waste — on a mobile connection it costs whole seconds. Resizing it sensibly and serving WebP or AVIF typically saves 60 to 80 percent. That is exactly why we built the image compressor: it runs entirely in your browser, converts to WebP and AVIF, and shows you before and after side by side.

Lazy loading in the wrong place. loading="lazy" is excellent — for everything below the fold. On the hero image it backfires: the browser waits until it knows the image will be visible, and only then starts fetching. The image that defines your LCP belongs in the HTML without lazy loading, ideally with fetchpriority="high".

Images injected by JavaScript. If a slider or gallery script inserts the hero image after the fact, the browser's preload scanner cannot spot it while parsing the HTML. The result is a long load delay even though the file itself is small.

A slow server. Anything over 800 milliseconds of TTFB is a warning sign. The usual causes are uncached database queries, oversold shared hosting, or a server on a different continent from your visitors. A full-page cache or a CDN often changes more here than any amount of frontend work.

Render-blocking resources. Every stylesheet and every script in the head stops rendering until it has loaded. Inline the critical CSS, load the rest afterwards, and add defer to your scripts.

CLS — when the page moves out from under your thumb

Cumulative Layout Shift is the metric everybody understands the moment they have suffered it: you go to tap a link, a banner loads in above it, everything slides down, and your finger lands on an ad instead. CLS puts a number on precisely that. It is not a time value but a dimensionless score, combining how much of the screen moved with how far it moved.

Two things are worth knowing. First, only unexpected shifts count. A menu expanding because you clicked it is not a layout shift — anything within 500 milliseconds of a user interaction is excluded. Second, it is measured across the whole life of the page, in rolling five-second windows. A banner that appears after thirty seconds of scrolling and shoves everything down counts just as much as one during load.

The usual causes of a poor CLS

• Images without width and height. With no dimensions the browser cannot reserve space. It lays out the text, the image arrives, everything moves. The fix is two attributes: set width and height, and modern CSS derives the aspect ratio and holds the space open.
• Ads and embeds with no reserved slot. Ad units, maps, video players, cookie banners and newsletter pop-ups push themselves into finished text. Reserve the area up front with a fixed-height container, even if it sometimes stays empty.
• Fonts that change text width when they swap. If a system font renders first and your brand font swaps in, line lengths and wrapping change. Preload your most important font and define a fallback with similar metrics.
• Content injected at the top. A notification bar that appears after load shifts the entire page down. Either render it from the start or lay it over the content as an overlay.

CLS has the best effort-to-payoff ratio of the three. Most sites get from 0.3 to under 0.05 with a handful of attributes and one reserved container — an afternoon's work, not a quarter's roadmap.

INP — the metric that replaced FID

Interaction to Next Paint measures how long it takes for the page to respond visibly to an input. The clock starts at a click, tap or keypress and stops when the browser paints the next frame. All interactions during a visit are considered, and the page's INP is effectively the worst of them (with the top outlier discarded once there have been a great many interactions).

In March 2024 it replaced FID, and that was overdue. First Input Delay only measured the delay before the first interaction began being processed. What happened afterwards — the actual work, the repaint — was ignored entirely. The result was a metric that over 90 percent of pages passed, including plenty that felt sluggish. INP watches the whole chain and is far more honest about it. Predictably, more pages fail.

Why our test shows no INP value

This is where cheaper tools quietly fudge things, so let us be blunt: INP cannot be measured in a lab. The value only exists once a human interacts. An automated page load does not click, so there is no interaction, so there is no INP. Lighthouse reports no lab value for it — and we are not going to make one up.

What we show instead is Total Blocking Time. TBT sums up every stretch where the main thread was busy with a single task for more than 50 milliseconds. Those are exactly the windows in which the page could not have responded to a click. That makes TBT the best lab-available proxy for INP: a high value almost certainly means poor INP in the field. The reverse does not hold, though — a page with clean TBT can still have terrible INP if the click handler itself is expensive.

The usual causes of a poor INP

• Too much JavaScript. Every kilobyte has to be transferred, parsed and executed, and the main thread is blocked while it happens.
• Long, uninterrupted tasks. A script that computes for 400 milliseconds straight blocks every input for that whole time. Break large tasks into chunks so the browser can handle input in between.
• Expensive event handlers. If a click first fetches data and then rebuilds half the DOM, the response is slow. Show visible feedback immediately and do the heavy work afterwards.
• Third-party scripts. Tracking, chat widgets, ads, consent managers — they occupy the main thread with work your visitor gains nothing from.
• An enormous DOM. Tens of thousands of elements make every layout calculation expensive, and one happens on every interaction.

Lab data vs. field data: why they are allowed to disagree

This is the most important distinction on the page, and it explains nearly every bit of confusion around Core Web Vitals.

Lab data — what this test produces — comes from a single controlled page load. A datacentre server loads your page in a real Chrome, simulating a mid-range phone on a throttled connection. The upside: it is repeatable, available instantly, and it shows you causes. You can make a change and see two minutes later whether it worked. The downside: it is a simulation. A server in a datacentre is not your visitor on a train.

Field data comes from the Chrome User Experience Report (CrUX): real measurements from real Chrome users who opted in, aggregated over the last 28 days. This is what Google actually uses for ranking and what you see in Search Console. The upside: it is the truth. The downsides: it needs enough traffic to exist at all, it takes weeks to reflect a change, and it will not tell you why anything is slow.

Typical ways the two diverge:

• Good in the lab, bad in the field: your visitors are on older devices or worse networks than the simulation assumes. Or a cookie banner blocks rendering for real users while the test run never sees one.
• Bad in the lab, good in the field: returning visitors have your assets cached. The test always starts with an empty cache — the worst case by design.
• INP only bad in the field: the classic. There is no interaction in a lab run, so your sluggish search box only shows up once real people use it.

The sensible workflow uses both: field data from Search Console tells you whether and where you have a problem. A lab test like this one tells you why — and lets you verify a fix in minutes rather than weeks.

The performance score: useful, but not a report card

The large number in the coloured ring is the Lighthouse performance score. It is a weighted blend of five lab metrics — Total Blocking Time and Largest Contentful Paint carry most of the weight, joined by Speed Index, First Contentful Paint and Cumulative Layout Shift. Green starts at 90, red below 50.

Three honest caveats. First, the score is not what feeds into rankings. Google evaluates Core Web Vitals from field data, not from this lab score. Second, it moves around. A five to ten point difference between two runs of the same page is normal, because network conditions and server load vary. Chasing individual points is measuring noise. Third, reaching 100 is not a goal in itself. Going from 45 to 80 visibly changes your visitors' experience. Going from 92 to 98 usually costs days and nobody notices.

How much do Core Web Vitals really move rankings?

There is a lot of exaggeration here, in both directions. The sober answer:

Page experience is an additional signal, not a primary factor. Google has said so repeatedly and clearly: a page with world-class vitals will not rank for a topic it does not cover. Relevance and content quality come first. Between two pages with comparably good content, speed can tip the balance — which is why "tiebreaker" is the fairest word for it.

The indirect effect is the bigger one, and almost nobody talks about it. Faster pages have measurably lower bounce rates, more pages viewed per visit and higher conversion rates. Those relationships hold up across industries. They affect your revenue regardless of whether Google awards a ranking point for them.

And one thing is unambiguous: a page that is red in the field — LCP over four seconds, CLS above 0.25 — has a genuine problem worth fixing. Not because of Google, but because people leave. Going from red to green always pays. Going from green to slightly greener rarely does.

A sensible order to work through

1. Images first. Size, format, compression. It is the most common LCP cause and the fastest win. The image compressor handles it in one go.
2. Prioritise the LCP element. No lazy loading on the hero image, add fetchpriority="high", preconnect to any third-party image host.
3. Reserve space. Width and height on every image, fixed heights for ad slots and embeds. That usually settles CLS entirely.
4. Check your server response. Over 800 ms TTFB? Caching and a CDN will do more here than any further frontend work.
5. Audit your JavaScript. What is genuinely needed? Third-party scripts are the usual suspects and are more expendable than everyone assumes.
6. Unblock rendering. Critical CSS inline, the rest async, scripts deferred.
7. Then check the field. Two to four weeks later, Search Console will tell you whether it reached real users.

How this test works

When you press "Run test", your address goes to our server. There, Google Lighthouse runs inside a real Chromium — the same software behind PageSpeed Insights and your browser's developer tools. Your page is loaded in full, with a simulated mid-range phone and a throttled connection, and measured while it renders. That usually takes 30 to 60 seconds. While it runs we show you the actual phase and the real elapsed time, not an invented progress bar.

This is a deliberate exception in our toolbox. The image compressor, the QR code generator and the meta title generator run 100 percent in your browser and upload nothing at all. Here that is technically impossible: for security reasons, a browser is not allowed to read the load timings of another domain. So the measurement has to happen server-side — and we would rather say that plainly than bury it. The address you enter stays in memory for at most 15 minutes so you can fetch the result, then it is discarded. No database, no history, no account.

Frequently asked questions

Measurements are taken with Google Lighthouse in a headless Chromium on our server, using the default simulated mobile and desktop configurations. Results are lab data from a single page load and may differ from the field data shown in Google Search Console. The thresholds quoted here follow Google's official Core Web Vitals definitions (as of 2026).