Paste any URL and see exactly how fast your page loads — DNS lookup, connection time, TLS handshake, server response, and total transfer time. Real measurements from a real request, not a simulated score.
Fetching page and measuring timings…
Ask ten developers what "a fast website" means and you'll get ten different answers. Under 1 second? Under 3? Faster than the competitor? The truth is that page speed isn't a single number — it's a stack of measurements that each tell you something different about where the time is going.
We built this Speed Checker because most "speed test" tools show you one opaque score and call it a day. A number between 0 and 100 tells you almost nothing about what to fix. If your TTFB is 2 seconds because your server is doing expensive database queries on every request, no amount of front-end optimization will help. If your TTFB is 80ms but your total load time is 6 seconds, the problem isn't the server — it's everything the browser has to fetch afterward.
This tool measures a real HTTP request from start to finish and shows you exactly where every millisecond went. The result is a breakdown you can actually act on.
When a browser requests a page, it goes through several distinct phases. Each one can be a bottleneck for a different reason. Our timing chart breaks down the total load time into these phases:
The time to translate your domain name into an IP address. On a fast DNS provider like Cloudflare or Google DNS, this is typically 10–50ms. If you're seeing 200ms+, your DNS provider is slow or your nameservers are geographically distant from your visitors. Switching to a global anycast DNS provider is usually a five-minute change and often the single biggest win available.
The time to establish a TCP connection to the server. This depends mainly on physical distance (speed of light through fiber is a hard limit) and network hops. If your server is in Frankfurt and your visitor is in Sydney, you're looking at 300ms minimum just for the handshake. This is why CDNs help so much — they put a server physically closer to the visitor.
For HTTPS sites, the cryptographic negotiation between browser and server. Well-configured modern servers complete this in one round-trip (TLS 1.3) or two (TLS 1.2). If you're seeing over 500ms here, check that your server supports TLS 1.3 and is using modern ciphers — legacy cipher suites add extra handshake round-trips.
The time between sending the request and receiving the first byte of the response. This is what "Time to First Byte" actually means, and it's the single most important metric for server health. Under 200ms is excellent. 200–500ms is acceptable. Over 1 second means your server is doing too much work per request — usually database queries, uncached API calls, or heavy server-side rendering.
The time to transfer the response body. For a well-compressed HTML page (usually 20–60KB), this is dominated by bandwidth, not size. If you're seeing multiple seconds here, either the page is huge (a common problem with pages that inline huge images or base64 data) or the user's connection is slow. Compression and CDNs are your two tools.
If you're troubleshooting page speed and you had to pick only one number to watch, pick TTFB. Here's why: every other optimization is bound by it.
If your server takes 1.5 seconds to start sending data, no amount of image compression or CSS minification will make the page feel fast — the user is staring at a blank screen for a second and a half before anything renders.
And TTFB is almost always a server-side problem, which means it's fixable. The three most common causes we see:
We've seen sites go from 2.1s TTFB to 140ms TTFB by adding Redis caching for the top 5 database queries. Same server, same code, one configuration change. The site felt completely different to use afterward.
This is the easiest win in existence. Enabling gzip or Brotli compression on your web server reduces the size of HTML, CSS, and JavaScript by 60–80%. Every modern server supports it. Every modern browser supports it. If your site isn't compressed, you are literally sending several times more data than necessary over every single page load.
Our tool checks the Content-Encoding header on every test and
flags uncompressed pages as an issue.
Sites that load 80+ resources on the homepage — analytics, chat widgets, fonts, tracking scripts, five different CSS frameworks — routinely take three to four times longer to fully load than they need to. Audit your scripts: do you really need that third analytics tool? Is that font file actually being used? Lazy-load anything below the fold.
Static assets (images, CSS, JS) should be served with long
Cache-Control max-age values so returning visitors don't
re-download them. If your headers don't include caching directives, every
visit to your site re-fetches every file.
http://example.com → https://example.com →
https://www.example.com → https://www.example.com/home.
Each redirect is a full round-trip and costs 200–500ms. Consolidate to a
single canonical URL and update internal links accordingly.
HTTP/1.1 can only load one resource at a time per connection. HTTP/2 multiplexes dozens of requests over a single connection. HTTP/3 goes further with a UDP-based transport. If your server still only supports HTTP/1.1, you're leaving 20–40% performance on the table for pages with many resources.
Based on thousands of checks we've run, here's what different score ranges actually mean in practice:
Yes, but with important nuance that most articles miss. Page speed is a tie-breaker signal in Google's ranking algorithm, not a primary ranking factor. If you and a competitor are otherwise equal in content quality, backlinks, and relevance, the faster site wins.
But the real SEO impact of speed is indirect and much larger:
Fixing a genuinely slow site is usually one of the highest-leverage SEO improvements you can make. Fixing an already-fast site from 92 to 96 is usually not worth the effort.
Work through these in order — each step builds on the previous:
Content-Encoding is missing from your headers, this is a 5-minute fix.After each change, re-run this check to see the impact. We deliberately show raw millisecond measurements, not a black-box score, so you can see exactly which change moved the needle.
Want to test how your server handles load and security at the same time? Run our SSL Checker to verify your HTTPS setup, and the full security scan for a complete picture of your website's health.
We make a real HTTP request to your URL from our server, following redirects the way a browser would. During the request, we capture cURL's detailed timing metrics — DNS lookup time, TCP connection time, TLS handshake time, time to first byte, and total download time. We then parse the response and analyze compression headers, caching headers, and resource counts.
Unlike tools that simulate a slow connection or render the page in a headless browser, this tool measures the actual network and server behavior. That makes it fast and reliable, but it also means it measures server-side metrics rather than pixel-level rendering performance.
For the HTML page itself (what this tool measures), you want to be under 1 second. Under 500ms is excellent. Under 200ms is world-class.
For the fully rendered page including all resources, the modern standard is under 2.5 seconds for Largest Contentful Paint (LCP). Google's Core Web Vitals treats 2.5s as the "good" threshold.
Keep in mind that page speed varies based on the visitor's location. A site that loads in 400ms from your office might take 1.2 seconds from another continent. This is why CDNs matter for global audiences.
TTFB (Time to First Byte) is almost always a server-side issue. Common causes:
The fixes are typically: add Redis or Memcached caching, move to a faster host or VPS, put Cloudflare or another CDN in front, or profile the code and optimize the slow parts.
Yes. Enabling gzip or Brotli compression reduces the size of HTML, CSS, and JavaScript by 60–80%. A 100KB HTML page becomes 25KB. A 300KB CSS file becomes 60KB.
On a fast connection, the difference is barely noticeable. On mobile or slow connections, it can mean the difference between a 2-second and a 6-second load. Compression is a one-line change in most web server configs, and there's no downside — every modern browser supports it.
Yes, if your server supports it. HTTP/2 lets the browser load many resources over a single connection instead of waiting for each one sequentially. HTTP/3 builds on that with a lower-latency UDP-based transport.
Most modern web servers (Nginx, Apache 2.4.17+, Caddy, LiteSpeed) support HTTP/2 out of the box. Cloudflare and other CDNs enable HTTP/3 for free with a single toggle.
Practical impact: on pages with 30+ resources, HTTP/2 can cut full load time by 20–40% compared to HTTP/1.1.
Network conditions are never perfectly stable. Even a millisecond- level variance in routing, server load, or your own connection can produce a 5–15% difference between runs.
For a fair comparison, run the check a few times and look at the range. If the same page loads in 340ms one minute and 1.8 seconds the next, that's a real problem — but if it varies between 340ms and 410ms, that's normal noise.
Yes, but the effect is usually indirect. Google has confirmed page speed as a ranking signal since 2010, and the Core Web Vitals metrics became direct signals in 2021. But the practical impact comes through user behavior:
In practice, fixing a genuinely slow site is one of the highest- leverage SEO improvements you can make. Improving an already fast site from 92 to 96 usually isn't worth the effort.
Google PageSpeed Insights uses Lighthouse, which runs a headless Chrome browser to simulate loading the page. It gives you a performance score based on the Core Web Vitals and various rendering metrics.
Our tool measures the raw network timing of a single HTTP request. It doesn't simulate a slower connection or run JavaScript. What it gives you instead is precise millisecond-level detail about where the server-side time is going — which PageSpeed Insights obscures behind a single score.
The two tools are complementary. Use this one to diagnose server and network issues, and PageSpeed Insights for rendering performance.
Any publicly accessible website. Speed checks are read-only and anonymous — we just make a normal HTTP request the way any browser would.
Private and internal addresses (localhost, 192.168.x.x, 10.x.x.x) are blocked for security reasons. Sites behind a VPN or requiring authentication can't be checked either.
Yes — completely free, no signup required. There's a soft limit of 5 checks per hour per browser, since each check makes a real network request and consumes server resources. That limit is more than enough for normal use.
If you need continuous monitoring with historical tracking and alerts, that's available in our paid plans. Creating a free account is the first step.
Get quick access to your security scans directly from your device.
Tap the Share icon below, then select "Add to Home Screen".