Free Website Speed Test: Core Web Vitals and Lighthouse

What a Lighthouse speed test report looks like

This is our own homepage, tested on 27 August 2026 (Mobile, throttled connection). We are publishing our real numbers rather than a flattering example, because the gap between the two halves of this report is the most useful thing on the page.

Read the two columns against each other. The lab reports an LCP of 5.2 seconds and a performance score of 65, which looks alarming. Real users see 2,243 milliseconds, which Google rates as good. That is not a contradiction: the lab deliberately simulates a throttled mid-range phone so the result is reproducible and pessimistic, while the field column is what actually happened to real visitors over the past month.

The genuine problem is in the field column, and the lab score never mentions it. Interaction to Next Paint is 545 milliseconds against a 200ms target, so this page loads acceptably and then responds slowly when someone taps. No lab run can measure INP at all, which is why a tool that reports only a Lighthouse score can tell you a page is fine when its users disagree.

What are Core Web Vitals? An LCP, INP and CLS checker in one test

Core Web Vitals are the handful of user-experience metrics Google uses as a ranking signal. Three of them count directly, and two more explain why the others look the way they do.

LCPLargest Contentful Paintgood: under 2.5s

When the biggest thing on screen, usually the hero image or headline, finishes painting. It is the closest single number to "did this page feel like it loaded".

INPInteraction to Next Paintgood: under 200ms

How long the page takes to visibly respond after someone taps or types. It replaced First Input Delay because it measures every interaction, not just the first, and it is the vital most sites fail.

CLSCumulative Layout Shiftgood: under 0.1

How much the page jumps around while loading. Usually caused by images without dimensions, injected banners, or fonts swapping late.

FCPFirst Contentful Paintgood: under 1.8s

When the first text or image appears. It tells you whether the delay is in getting anything at all on screen, or in finishing the job.

TBTTotal Blocking Timegood: under 200ms

How long JavaScript held the main thread and made the page unresponsive. It is a lab metric, and it is the best available proxy for INP, which no lab test can measure directly.

What is a good website speed score?

On Google PageSpeed, 90 to 100 is fast, 50 to 89 needs work, and 0 to 49 is slow. Aim for 90 or better on mobile, because mobile is what Google indexes and what most of your visitors are holding. Treat the score as a summary rather than the goal: it is a weighted blend of the lab metrics, so two sites on the same score can need completely different fixes.

Why is my mobile score lower than desktop?

Because the mobile test throttles the connection and simulates a slower device, which is realistic for real visitors. A large gap between the two is diagnostic in itself: it almost always means heavy JavaScript, oversized images, or render-blocking resources, all of which cost a phone far more than a laptop.

How do I make my website faster?

Fix the biggest LCP and blocking-time offenders first: they move the score most and they are what real users feel. In rough order of return:

1. 1Compress images, serve WebP or AVIF, and lazy-load anything below the fold
2. 2Defer and code-split JavaScript, and delete what is unused
3. 3Preload the LCP image so it is not discovered late
4. 4Put a CDN in front of the origin and cache at the edge
5. 5Inline the critical CSS and load the rest asynchronously

How this speed test compares

PageSpeed Insights and GTmetrix both run Lighthouse. We use the same PageSpeed Insights API, then lay out lab and field Core Web Vitals together so you can see when they disagree, and link speed to Agent Readiness, eDR, and Trust when you want the full picture.

Yes   Partial   No. Comparison reflects publicly documented capabilities and is updated periodically.

Feature details

Comparison reflects publicly documented capabilities and is updated periodically.

Speed feeds three other things we measure

A slow site is rarely only a slow site. The same numbers turn up in three other checks, so it is worth running them together once you have a baseline.

• Agent Readiness scores response-time consistency in its Quality category, because an agent calling your site pays the same latency a visitor does, on every request in a chain.
• Effective Domain Rating uses site health as one of its four signals, alongside where you rank and whether AI assistants cite you, to show whether your backlink authority is translating into visibility.
• Trust and Reputation Checker reads the posture around the site, and slow or failing responses are part of the impression it leaves.

Website speed test FAQ

What is a good website speed score?

On Google PageSpeed, 90 to 100 is fast, 50 to 89 needs work, and 0 to 49 is slow. Aim for 90 or better on mobile, because mobile is what Google indexes and what most visitors are using.

What are Core Web Vitals?

Core Web Vitals are the user-experience metrics Google uses as a ranking signal: Largest Contentful Paint (loading, good under 2.5s), Interaction to Next Paint (responsiveness, good under 200ms), and Cumulative Layout Shift (visual stability, good under 0.1).

Why is my mobile score lower than desktop?

PageSpeed tests mobile on a throttled connection and a slower simulated device, which is realistic for real visitors. A big gap between the two usually means heavy JavaScript, oversized images, or render-blocking resources, all of which hurt phones far more than laptops.

How do I make my website faster?

Compress and lazy-load images, serve modern formats like WebP and AVIF, cut and defer unused JavaScript, put a CDN in front of your origin, and preload the largest element (usually the hero image or heading). Fix the biggest LCP and TBT offenders first, since they move the score most.

Does this use Lighthouse?

Yes. The test runs a full Lighthouse analysis through the Google PageSpeed Insights API, so the engine, the audits and the scoring are Google's, not a reimplementation. That is why the numbers match what you would get from PageSpeed Insights directly.

Is this the same as Google PageSpeed Insights?

It is the same underlying analysis with the results laid out differently. We show all four category scores together, put the lab metrics and the real-user field data side by side so you can see when they disagree, and turn the failing audits into a list you can act on. If you only want the raw Google report, PageSpeed Insights gives you that.

Why do the lab and field numbers disagree?

They measure different things. The lab result is one simulated load on a throttled mid-range phone, chosen to be reproducible and pessimistic. The field result is the 75th percentile of what real Chrome users actually experienced over the past month. Our own homepage is a good example: the lab reports an LCP of 5.2 seconds while real users see 2,243 milliseconds, which Google rates as good. When the two disagree, the field number is the one Google scores you on.