Page speed test that shows the whole waterfall
Enter a URL. We time every stylesheet, script, font and image — DNS, connect, TLS, wait, download — and mark the files that stop your page from painting.
What you'll get: an example waterfall
This is a hand-built example of a small shop page. Drag across the timeline to move the orange finish line; tap a row to see its phases. Notice how vendor.js — a synchronous script in the <head> — holds first render until 858 ms even though the HTML arrived at 487 ms.
- 487 ms
- 152 ms
- 206 ms
- 361 ms
- 333 ms
- 207 ms
- 508 ms
- 184 ms
- 86 ms
- 154 ms
- 526 ms
Hover or drag across the timeline to drop the finish line; tap a row for its full timing breakdown.
How to read the bars
Each row is one request, in the order it started. The coloured segments are the phases Chrome DevTools and WebPageTest also use:
- DNS
- Turning the hostname into an IP address. Only appears the first time a host is contacted.
- Connect
- The TCP handshake — one round trip to the server.
- TLS
- Negotiating encryption for HTTPS. One extra round trip with TLS 1.3, two with TLS 1.2. See it step by step.
- Wait
- Time to first byte after the request was sent: server think-time plus one round trip. Test TTFB on its own.
- Download
- Receiving the body. Long download bars mean big files or a slow link.
A long row isn't automatically a problem. What matters is what sits on the critical path: the HTML, then every stylesheet and synchronous script in the <head>. The browser won't paint until those are done — we call that moment render unblocked and draw it as a dashed line. Everything after that line can still be slow without delaying the first paint. The waterfall guide walks through five patterns worth recognising.
Why is my website slow? The usual suspects
- A slow server response. If the first row's green wait segment is over ~600 ms, no front-end fix will help until the backend or cache does.
- Render-blocking files on other domains. A font stylesheet or script on a third-party host needs its own DNS + connect + TLS before it can even start. Check render-blocking resources.
- Chains. CSS that
@imports more CSS, which then loads a font: three round trips in a row, visible as a staircase in the waterfall. - Heavy images and scripts. Sort by size in the page size checker; the hero image is often bigger than everything else combined.
- Redirects.
http → https → wwwcan cost several hundred milliseconds before the real page even starts.
Once the network side is clean, check how it feels to real visitors with the Core Web Vitals checker.
Questions developers ask
What does this page speed test measure?
It downloads your page from a server, times every request it can discover in the HTML and CSS (stylesheets, scripts, fonts, images, iframes) and splits each one into DNS lookup, TCP connect, TLS handshake, waiting for the first byte and download. The result is drawn as a waterfall so you can see which file held up the rest.
How is this different from PageSpeed Insights or Lighthouse?
Lighthouse loads your page in an emulated phone and reports lab metrics and a 0–100 score. LoadTime skips the score and shows the network timeline itself: every request, when it started, what it waited on, and which ones block rendering. Use both — the score tells you that something is slow, the waterfall tells you what.
Why are my results different from Chrome DevTools?
This test runs from a data-centre server with cold connections and does not execute JavaScript, so resources injected by scripts (tag managers, lazy widgets) are not fetched. Your browser has warm DNS, cached files and may use HTTP/2 or HTTP/3. For a recording of exactly what your browser did, export a HAR file from DevTools and open it in the HAR analyzer.
What is a good page load time?
Aim for a server response (TTFB) under 0.8 s and a Largest Contentful Paint under 2.5 s at the 75th percentile of real visits — these are the thresholds Google publishes on web.dev. "Fully loaded" time matters less than when the main content becomes visible.
Is the test free, and do you store my URL?
Yes, it is free with no account. The URL is sent to our test function to be fetched and is not stored on our side. Your last few tests are saved only in your own browser (localStorage) so you can re-run them; you can clear that list at any time.
Which pages can I test?
Any public http or https page on the standard ports. Private addresses, localhost and intranet hosts are refused. Pages behind a login will only show the login page — use a HAR file for those.