How to Compare Website Speed (And What the Numbers Actually Mean)

Why comparing website speed is useful

A PageSpeed score on its own tells you little. Is 68 good or bad? It depends entirely on context — your industry, your platform, and most importantly, how your competitors are scoring.

Comparing your site speed against a specific competitor gives you a concrete benchmark. Instead of chasing a theoretical maximum, you can focus on closing a measured gap. And if your competitor is already passing Core Web Vitals while you are not, you know the ranking impact is real.

What to measure when comparing site speed

Not all speed metrics are equally important. Here is what to focus on and why:

PageSpeed score (0–100)

This is the composite score from Google's Lighthouse tool. It combines several performance metrics into a single number. Scores above 90 are considered good, 50–89 need improvement, and below 50 are poor.

The composite score is useful as a headline number, but do not optimise for the score in isolation — optimise for the underlying metrics.

Core Web Vitals

These are the three metrics Google uses as ranking signals:

LCP (Largest Contentful Paint) — how long the main content takes to load. Good: under 2.5 seconds. Poor: above 4 seconds.

INP (Interaction to Next Paint) — how quickly the page responds to clicks and taps. Good: under 200ms. Poor: above 500ms.

CLS (Cumulative Layout Shift) — how much the layout moves while loading. Good: under 0.1. Poor: above 0.25.

When comparing two sites, a site that passes all three Core Web Vitals has a ranking advantage over one that fails, regardless of the composite score difference.

TTFB (Time to First Byte)

TTFB measures how long your server takes to respond. It is not a Core Web Vital but it is the foundation of all other metrics — a slow server response delays everything else. Compare TTFB between two sites to understand whether a speed gap is a server problem or a frontend problem.

FCP (First Contentful Paint)

FCP measures when the first content appears on screen — the first moment a visitor sees something rather than a blank page. A low FCP reduces perceived load time even when total load time is similar.

How to run a speed comparison

The simplest approach is to use Loadzen's [website speed comparison tool](/compare). Enter both URLs and you will get:

For a more manual comparison, you can run both URLs through Google PageSpeed Insights separately and compare the numbers. The limitation is that you have to do this one at a time and the results can vary slightly between runs.

How to interpret the results

If both sites pass Core Web Vitals: The speed difference is less likely to affect rankings directly. Focus instead on perceived performance — which one feels faster to use — and on conversion rate optimisation rather than raw scores.

If one site passes and the other fails: The passing site has a ranking advantage. If your competitor passes and you do not, closing that gap should be a priority before any other SEO work.

If both sites fail: The comparison still tells you how much ground you need to close. If you are at position 57 and they are at position 72, you are already performing better than your competitor despite both failing.

If the gap is large (20+ points): Investigate TTFB first. A large score gap usually traces back to hosting infrastructure rather than frontend optimisation. A site running on a fast CDN with server-side caching will consistently outperform one on shared hosting regardless of image compression or JavaScript bundling.

Common mistakes when comparing website speed

Comparing mobile to desktop results. Always compare the same device type. Mobile scores are almost always lower than desktop. Google uses mobile performance for ranking, so compare mobile to mobile.

Comparing different page types. Homepage scores are almost always higher than product or category pages. Compare like with like — your product page against their product page.

Taking a single result as definitive. PageSpeed scores can vary by 5–10 points between runs due to network conditions and server load. Run two or three comparisons and use the average.

Ignoring field data. Lab scores from tools like PageSpeed Insights are simulated. If you have access to Search Console, check the Core Web Vitals report for field data from real visitors — this is what Google actually uses.

What to do after comparing

If your site is slower than a competitor, the priority order is:

1. Fix any failing Core Web Vitals — these have the most direct ranking impact

2. Address TTFB if above 600ms — this is foundational

3. Optimise images — usually the highest-impact change on the frontend

4. Defer or remove unused JavaScript — reduces main thread blocking

5. Enable compression and browser caching — low-effort, permanent gains

Run a [Loadzen speed check](/compare) on both sites to get a full breakdown with prioritised fixes, then compare again after you have worked through the list.