All tools

Website Speed Test

Enter a URL to measure how fast it responds: latency (time to first byte) and total time to download the page, from the median of three runs. Redirects are timed too, on their own. Any URL can be tested, not just a tracked Dodolytics website. Free tool, nothing you test is stored.

Two honest limitations, not glossed over: the times are for the page's own HTML response, not a full rendered-page load (the images, scripts, and stylesheets in the HTML are weighed, but on-screen render time isn't measured, since this app has no headless browser to measure that with); and the test runs from this app's own server, not from your location or several regions the way some commercial speed-test tools do.

A test takes a few seconds, and up to 30 for a very slow page.

How to use

  1. 1

    Enter a URL in the field above. A bare domain or a full URL both work.

  2. 2

    Click Run speed test.

  3. 3

    See latency and load time from the median of three runs, transfer size, a rating for each time, a list of what to fix, the page weight with its largest files, a full DNS/connect/TLS/server-response/download breakdown, and a redirect-hop table if the URL redirected.

Tip: you can test any publicly reachable URL, not just a tracked Dodolytics website.

What is a website speed test tool?

A website speed test tool measures how fast a URL actually responds: how long the server takes to send back its first byte (latency), and how long the full response takes to download. Any redirects along the way are timed too. It gives you real, measured numbers instead of guessing whether a page "feels slow."

How do I use it?

Enter a URL above. This tool follows each redirect hop, then fetches the final page three times and shows the median run, so one slow or fast moment does not decide the result. Results show latency (time to first byte), total load time, transfer size, and a full DNS/connect/TLS- handshake/server-response/download breakdown for the page actually tested, plus a redirect-hop table when more than one hop occurred. Each headline time gets a rating, and a "What to fix" list checks compression, HTTP/2, HTTPS, cache headers, redirects, and the server's own response time. A "Page weight" section counts and weighs the images, scripts, and stylesheets that the HTML asks for. The times are honestly for the page's own HTML response only, not a full rendered page, since this app has no headless browser to measure that with, and the test runs from this app's own server, not from your location or several regions the way some commercial speed-test tools do.

Why is it useful?

  • A slow server response hurts both visitor experience and SEO: search engines factor page speed into ranking.
  • Quickly spots a redirect chain silently adding latency to every single visit to a page.
  • Useful right after a hosting or CDN change, a DNS migration, or general performance tuning: a real before-and-after measurement, not a guess.
  • Free, no sign-up required, and nothing about a test is stored: test any URL, not just a site you already track.

FAQ

Is this tool free?

Yes, no login required either.

Do you store the URLs I test?

No. Nothing about a test (the URL, the result, or that it happened at all) is saved anywhere. It's shown once, in the same response, and gone.

Does this measure a full page load, like images and JavaScript?

In part. The times are for the page's own HTML response only. The Page weight section then downloads the images, scripts, and stylesheets that the HTML asks for, and shows how many they are and how large. On-screen render time is not measured, since this app has no headless browser to measure that with.

Does the test run from my own location?

No. It runs from this app's own server, not from your location or several regions the way some commercial speed-test tools do. Treat the numbers as a consistent baseline for comparison, not an exact match to what a visitor near you would see.

Why does a redirect chain show up?

It only appears when the URL you tested actually redirected at least once. Each hop's own status and time are shown, since a redirect chain can quietly add time to every visit to that page.

What does each part of the timing breakdown mean?

DNS lookup is resolving the domain to an address. Connect is opening the TCP connection. TLS handshake is negotiating HTTPS (blank for a plain http:// test). Server response is the time from request sent to the first byte received back. Download is the time from that first byte to the last one.

Why does the test run three times?

One request gives a number that changes from test to test. The first request is often slower, because the DNS answer and the server's own caches are cold. So the tool requests the final page three times and shows the median run, with the fastest and the slowest time next to it. If the page is very slow or larger than 2 MB, the tool makes fewer runs and says so.

Are redirects part of the times?

No. The headline times are for the final page alone. The redirects are followed one time, and the results page shows the time they added and each hop's own time.

How are the ratings decided?

Time to first byte is Good up to 800ms, Needs work up to 1800ms, and Slow above that. These are the limits that web.dev gives for this number. Load time is Good up to 1500ms, Needs work up to 3000ms, and Slow above that. Load time here is the HTML document alone, so these limits are this tool's own and not a public standard.

Where does the "What to fix" list come from?

From the numbers the test measured and from the headers of the page's own response. It checks redirects, HTTPS, HTTP/2, compression, the server's own response time, the DNS lookup, the HTML size, cache headers, and whether a CDN answered. It cannot see images, CSS, or JavaScript, so a page that passes each check can still be slow to show in a browser.

Why are there two sizes?

Transfer size is what the server sent over the network. If the server compresses its response (gzip or Brotli), the page is larger after your browser unpacks it, and that second number shows as "uncompressed". When the server does not compress, there is only one size.

Is there a limit on page size or test time?

Yes. The test stops the HTML download at 2 MB and stops the timed runs after 20 seconds, redirects included. The page weight covers the first 60 files, up to 5 MB each, and gets about 6 seconds. When a limit cuts a test short, the results page says so.

What does the page weight leave out?

Files that are not in the HTML itself: fonts, background images from a stylesheet, files that a script loads later, responsive image sources (srcset), video, and frames. A browser loads these too, so the real page is at least as heavy as the number shown, and often heavier.

Related tools

All tools