Web Speed Test

Free Web Speed Test — measure how fast your URLs actually respond

See Time to First Byte, total transfer time, HTTP status and page weight for any URL — and for up to 100 URLs at once — in a single side-by-side comparison table. No signup, no waiting for a 30-second Lighthouse audit, no limits. Run it whenever you suspect things are slower than they should be.

Why TTFB matters more than most people realise

Time to First Byte is the wait between sending a request and receiving the first byte back. It's the single best proxy for "is the server itself healthy?". Slow TTFB means:

• Lower search rankings. Google's Core Web Vitals lean on LCP, and LCP can never be faster than TTFB. A 1.5-second TTFB means LCP is at best 1.5 seconds — already in the "needs improvement" band.
• Higher bounce rate. Users abandon at roughly half the rate once a page starts rendering — but they can't start rendering until TTFB lands. Industry benchmarks show every 100 ms over the 300 ms mark measurably nudges bounce up.
• Lower conversions. Amazon famously found 100 ms = 1 % of sales. Walmart, Etsy and Shopify have published similar numbers. Money sits on that millisecond budget.
• Bigger AdWords / paid-traffic bills. Slow landing pages get penalised in Quality Score; you pay more per click for the same audience.
• Whole-stack health signal. A slow TTFB tells you the bottleneck is upstream of the browser — origin server, DB query, an external API, a missing cache. Fix it and every metric downstream improves.

What you get out of this tool

Who benefits, concretely

Backend engineers

Catch a slow query, a connection-pool exhaustion, a runaway N+1, an upstream API going to sleep — in the time it takes to type the URL. Bulk-run the URL set before and after every deploy and any regression > 100 ms jumps out immediately. No screen-recording, no devtools, no ssh-into-production.

DevOps / SRE

Reach for it during incidents: is the origin slow or is the CDN serving stale errors? TTFB tells you in a second. Sort a portfolio audit by TTFB and the misbehaving service is at the top of the table — without spelunking through Grafana.

SEO & performance leads

Google's PageSpeed Insights gives you one URL at a time, in ~30 seconds, with a 100-line report that mostly says the same thing every time: server response time. Our tool lets you sweep a sitemap, find the dozen URLs that are dragging the average down, and hand a focused list to engineering instead of a screenshot of a vague score.

E-commerce & product managers

A sub-200 ms TTFB on category and product pages is table stakes during peak season. Bulk-check the catalogue, find the SKUs where TTFB drifted past a second, and you've got a real conversion-rate-improvement plan instead of a hand-wave.

Agencies & freelancers

Auditing 30 client sites the day after a WordPress update? Paste the list, screenshot the table, attach to the quarterly report. The page-weight column doubles as a "did anyone upload a 12-megapixel logo PNG into the hero?" screen.

Marketing & paid-traffic teams

Every landing page in a campaign benchmarked side-by-side in seconds. Catch the variant that's accidentally shipping a 2 MB banner before you spend ,000 sending traffic to it.

Common payoffs — short stories

• Pre-deploy regression caught. Run the URL set before and after merging a PR. A 180 ms → 1.4 s TTFB on /checkout in two minutes — the engineer reverts before users notice.
• Wrong CDN cache key. Bulk-check the storefront; product pages return fast, category pages return slow. Cache-Control headers look fine; the cache key is missing the locale param. Fixed in a one-line edge config change.
• Plugin gone rogue. A WordPress portfolio audit shows three sites at 6-second TTFB. Same plugin, same recent update. Roll it back, file with the maintainer, problem isolated in 90 seconds.
• Hosting upgrade ROI. Before/after table proves the new server tier shaves 400 ms across the board — the receipt for the migration is ready for the next quarterly review.
• API endpoint sanity check. Same tool works on JSON endpoints. After a backend deploy, the team bulk-checks every public API URL in 30 seconds and confirms no endpoint regressed past 250 ms.

What this tool actually does

1. Validate URL. Auto-prefixes https:// when no scheme is given.
2. One GET. Issued via cURL with a 15-second timeout, user-agent YouMonit/1.0 (Speed test).
3. Follow redirects. Up to 4 hops; the URL column shows the final URL after the chain.
4. Time it. Capture cURL's STARTTRANSFER_TIME (TTFB) and TOTAL_TIME (full transfer).
5. Measure. Bytes downloaded, status code of the final response.

That's a single shot from our datacentre. Real users fetch your URLs from different geographies, on different connections, through their own DNS — those numbers will differ, but the relative comparisons stay valid.

Input accepted

• https://example.com/path — checked as is.
• example.com — auto-prefixed with https://; if the server redirects elsewhere, we follow and the URL column shows the final URL.
• Non-default ports are fine (https://example.com:8443/).

What this tool returns

URL

Final URL after redirects, not the one you typed. A common surprise: a 301 from www to apex, an HTTP→HTTPS upgrade or a CDN rewrite shows up here.

Status

HTTP status code of the final response — 200, 404, 500 etc. Redirects (301/302) are followed and don't appear here.

TTFB

Time to First Byte in milliseconds — DNS, TCP, TLS and the wait for the first byte of the response body. The single most useful "is the server slow today?" metric.

Total

Total request time in milliseconds, including the full body download. Total − TTFB ≈ how long the body took to land — useful for very large pages.

Size

Downloaded body size, formatted as B / KB / MB. Excludes headers and anything the page might lazy- load via JS (we don't execute JS).

Reading the numbers — useful baselines

These are sanity-check ballparks, not industry standards — adjust to your audience and use case.

TTFB < 200 ms

Excellent. Origin is either CDN-edge cached or genuinely well-tuned. Hold the line.

TTFB 200–600 ms

Typical for an origin without a CDN, or content that needs a small DB hit. Acceptable, but a CDN or output cache would cut it.

TTFB 600 ms – 2 s

Slow. SEO is paying for this. Look at server CPU, database queries, missing caches, external API blocking calls.

TTFB > 2 s

Critical. Something is actively wrong — cold start, cache-miss avalanche, upstream API timeout, or a plugin that just decided to spider your filesystem.

Size < 200 KB (HTML)

Lean. Modern frameworks frequently land here when SSR is done well.

Size > 2 MB (HTML)

Heavy. Usually inlined assets or an SPA shell that hauls its world up front. Audit candidates.

Bulk mode & export

Drop up to 100 URLs in the textarea, one per line. Each row is fetched sequentially; the comparison table is exportable to CSV / JSON / YAML / XML. Common workflows: pre-deploy timing snapshot, post-deploy regression check, quarterly portfolio audit, competitor benchmark, customer-handover proof point.

What this tool does NOT do (and why that's OK)

Designed-narrow on purpose. Each thing below has a dedicated tool that does it better — but for the origin-response-time question, this is the fastest answer you'll get.

• No browser rendering. No JS execution, no CSSOM, no painting — for those, run the URL through Google PageSpeed Insights or WebPageTest.
• No Core Web Vitals. LCP, FCP, CLS, INP, TBT, SI, TTI all need a real browser.
• No Lighthouse score. No 0–100 number.
• No mobile vs desktop. One sample per row, from our server. No throttling.
• No waterfall. Single request, no resource discovery, no critical-path analysis.
• No multi-region. Sampled from one location. Real users in Tokyo or São Paulo will see different absolute numbers; the relative ranking holds.
• No averaging. One sample per row. Re-run for stability under load.
• No TLS verify. Cert verification is off, so the tool also works against expired / self-signed certs.
• No per-phase split. Only TTFB + total.
• No response headers. See the HTTP headers tool when you want those.

Common reasons a check fails

• Timeout — the URL didn't respond within 15 seconds. Slow origin, firewalled, or genuinely down.
• Could not resolve host — DNS failure (typo, no public A/AAAA, expired domain).
• No response — connection accepted but nothing came back.
• Too many redirects — four hops weren't enough, usually a redirect loop.
• Invalid URL — input didn't pass URL validation after auto-prefixing https://.

If you need a full audit, not just origin timing

This tool answers "is the origin responding fast and at normal weight?". For "what does a real browser see?", run the URL through Google PageSpeed Insights or WebPageTest — those execute Lighthouse in a real Chrome and produce LCP, CLS, scores and a waterfall. They're slower (~30 seconds per URL), harder to bulk-run, and irreplaceable when you need the full picture. Use this tool to find the URLs worth deep-auditing, then deep-audit them.

Related tools that pair well

Combine with the HTTP headers tool to see Cache-Control / Server / CDN headers on the same URLs (and confirm caching is doing what you think), SSL / TLS checker when TLS itself looks like the bottleneck, TCP ping for raw connect-time isolation when you suspect the network, and DNS records lookup to verify hostname resolution.

Get started

Paste one or more URLs in the form above and hit Lookup. Single submissions render as a detail card with every field; bulk submissions as a side-by-side comparison table you can scroll horizontally, sort and export. No signup, no rate limit, completely free.