**API & Website Speed**
Test Enter your URL and get a website speed check. Get insights on page load, header details and timing phases (DNS, Connect, TLS, TTFB, Transfer) of the response.
**Global Speed Test**
Monitor latency performance in different regions to ensure quick load times for users across 28 regions worldwide.
**Share the Results**
Quickly share the results of your website speed test with your team or clients. The results expire after 7 days, so you can easily collaborate on performance.
### What Is a Website Speed Checker?
A Website Speed Checker is an online tool that measures how fast your website or API responds when someone visits it. It analyzes various website performance metrics to help you understand which elements slow down your page load time.
Speed checkers can focus on two aspects of performance:
- **Client-side performance**, which includes metrics like First Contentful Paint (FCP), Largest Contentful Paint (LCP), and Cumulative Layout Shift (CLS) — all indicators of how quickly your site becomes visible and usable to visitors.
- **Server-side performance (or network performance)**, which looks at the technical steps of a request such as DNS lookup, TCP connection, TLS handshake, and server response time.
Understanding both sides helps you identify whether slowdowns are caused by your frontend assets or your backend infrastructure.
### What Is a Global Speed Checker?
A Global Speed Checker measures your website or API's latency and response time from multiple locations around the world. Instead of testing from just one data center, it runs checks from 28 global regions across 3 cloud providers, giving you a complete picture of your site's real-world performance.
## How to Test Your Website Speed
1. **Enter your URL.** Paste the full address including the scheme — `https://example.com`. Any public HTTP endpoint works, whether it serves a web page or a JSON API.
2. **Run the speed test.** openstatus sends one request from each of its 28 regions in parallel. The run takes about 20 seconds, bounded by the slowest region rather than the sum of all of them.
3. **Read the per-region results.** Each row is one region, sorted by total response time. Click a row to expand the timing phases — DNS, TCP connection, TLS handshake, TTFB, and transfer — along with the response headers and status code.
4. **Compare regions and share.** Look for regions several times slower than your fastest. Share the result with a link that expires after 7 days.
No account, no install, and nothing to configure. If you want the same check to keep running after you close the tab, that is [uptime monitoring](/uptime-monitoring) rather than a one-off test.
## What a Good Website Load Time Looks Like
This tool measures **server-side** load time — how long your infrastructure takes to answer, not how long a browser takes to paint the page. Read your result against these bands:
| Response time | Verdict | What it usually means |
| --- | --- | --- |
| Under 200ms | Fast | Served from an edge or a nearby origin. Nothing to fix. |
| 200–500ms | Acceptable | Normal for a single-region origin answering a distant request. |
| 500ms–1s | Slow | Users notice this. Usually an origin round trip plus unoptimised work per request. |
| Over 1s | Needs attention | Something is wrong — cold starts, an N+1 query, or no caching anywhere in the path. |
The important number is not the average — it is the **spread**. A site answering in 80ms from Frankfurt and 900ms from Sydney does not have a speed problem, it has a distribution problem, and the fix is a CDN or an edge deployment rather than a faster server.
Browser metrics like LCP, INP, and CLS are a separate question. They measure rendering, and they sit downstream of the numbers here — a slow server makes every one of them worse, but a fast server does not guarantee they are good.
For the target numbers on both halves — server response bands, Core Web Vitals thresholds, and why to judge them at the 75th percentile rather than the average — see [what is a good response time](/guides/what-is-a-good-response-time).
## Where the Speed Test Runs From
All 28 regions run on every test, so you see the full spread rather than a sample:
| Continent | Regions | Locations |
| --- | --- | --- |
| North America | 11 | Ashburn, Chicago, Dallas, Los Angeles, San Francisco, San Jose, Secaucus, Toronto, Washington, California, Virginia |
| Europe | 8 | Amsterdam ×2, Frankfurt ×2, Paris ×2, London, Stockholm |
| Asia | 6 | Singapore ×3, Tokyo ×2, Mumbai |
| South America | 1 | São Paulo |
| Africa | 1 | Johannesburg |
| Oceania | 1 | Sydney |
Several cities appear more than once because they are covered by different cloud providers — 18 regions run on Fly, 6 on Koyeb, and 4 on Railway. Testing the same city across providers is often how you tell a network problem apart from a provider problem.
## How We Measure
Each region opens its own connection and records the request in phases rather than as a single number:
- **DNS** — resolving the hostname. A slow figure here is a nameserver or TTL problem, not an application one.
- **TCP connect** — the round trip to open the socket. This is mostly distance, and it is the number a CDN improves.
- **TLS handshake** — negotiating HTTPS. Usually one extra round trip, more if the certificate chain is long.
- **TTFB** — time to first byte, from request sent to the first byte back. This is where your application's own work shows up.
- **Transfer** — streaming the rest of the response body.
Two caveats worth knowing. Connections are not reused between runs, so every test pays full DNS, TCP, and TLS cost — closer to a first-time visitor than a returning one. And each region contributes a single sample, which is enough to compare regions against each other but not enough to establish a baseline. Latency moves with traffic, deploys, and time of day, so one number from one moment is a snapshot, not a trend.
---
With openstatus, you can:
- Test how fast your API or website responds worldwide.
- Compare latency across different regions.
- Identify network bottlenecks.
- Monitor uptime and availability in real time.
Whether you want to test your website speed from Europe, Asia, North America, or beyond, our Global Speed Checker gives accurate, consistent data from distributed locations.
### Keep testing after the tab closes
This page runs one test, right now. A single sample tells you very little about a
slow endpoint — latency moves with traffic, deploys, and time of day.
[openstatus uptime monitoring](/uptime-monitoring) re-runs this exact check on a
schedule from the same 28 regions, keeps the history, and alerts you when response
time degrades rather than when the site is already down.
For the vocabulary behind the numbers above, see
[latency vs response time](/docs/concept/latency-vs-response-time).
If you'd like to request additional test regions or providers, feel free to contact us at [ping@openstatus.dev](mailto:ping@openstatus.dev).
## Frequently asked questions