Site speed comparator

Enter your address, get the median of three timed requests measured against Google's own speed thresholds and the real average across Lumiasoft's delivered projects.

Want this inside your own product?

Let's talk in a 45-min discovery call.

Book a call

When a page takes an extra second or two to load, nobody files a complaint, they just close the tab and go back to search. That lost visitor never shows up on an invoice, the phone just rings a little less. This tool sends three timed requests from your browser to the address you enter, takes the median response time, and checks it against Google's own web.dev thresholds: under 800 ms is good, over 1800 ms is poor, anything in between needs improvement.

The result relies on the median of three attempts rather than a single try, so one unusually slow moment doesn't skew it. The results screen also shows the average Lighthouse performance score across Lumiasoft's live projects, computed on every build straight from the real scores in src/data/works.js, not a number typed in by hand.

Some sites reject every outside request from a browser; when that happens the tool says so plainly instead of claiming the site is slow. Want to check your site's security posture as well as its speed? See the launch-readiness check. For how we set up the monitoring side after launch, the production-handoff section of our vibe-coded-app-to-production guide covers who gets notified and when. If your own site keeps landing in the slow band, LumiCare takes over speed, security and maintenance on a monthly basis.

Frequently asked

Does this tool send my address to a server?

No. The timed request goes straight from your browser to the address you type, it never passes through a Lumiasoft server, and no address is logged.

Why the median of three measurements instead of one?

A single request can land on one network hiccup and give a misleading number. Tools like WebPageTest and Lighthouse take the median of several runs for the same reason; this tool applies the same logic across three.

Where do the 800 ms and 1800 ms thresholds come from?

From the Time to First Byte (TTFB) section of Google's web.dev guidance: under 800 ms is good, over 1800 ms is poor, anything between needs improvement. This tool uses those thresholds as published, it doesn't invent its own.

If the result comes back "couldn't measure", does that mean my site is slow?

No. Some sites reject every outside browser request outright because of a firewall or server configuration. When that happens, the tool says it couldn't measure rather than making up a number.