Redirect Speed Test
Measure what your redirect chain actually costs — real per-hop latency on your own URL, not a published average. Free, no signup.
Why an average is the wrong answer
Ask how much a redirect slows a page down and you will be told 60ms, or 100 to 500ms, or “roughly a tenth of a second.” Those figures come from measurements between fast servers on good networks, and they are close to useless for deciding whether your chain is worth fixing. A hop to a server in the same datacenter and a hop that crosses an ocean, wakes a cold origin and renegotiates TLS are the same line in a redirect map and nowhere near the same wait.
So this test does not quote an average. It requests your URL, times every hop the server actually takes to answer, and adds them up. The total is the delay a real visitor sits through before the destination page is even allowed to start loading.
Reading the waterfall
Each row is one hop, with its status code, its URL and the time that server took to respond. The bar underneath shows that hop’s share of the slowest hop, so a single stubborn step is obvious at a glance. Amber bars are redirects — pure overhead. The final bar is the destination itself, which you were always going to pay for.
The number that matters sits above the list: total redirect delay. It excludes the destination, because that is the part flattening cannot give back. Everything else is time you can reclaim by rewriting one rule.
What the delay costs you
Redirect time lands in the worst possible place: before anything. The browser cannot request the destination’s HTML, cannot discover a stylesheet, cannot start a font download, until the last hop resolves. So the delay does not slow your page down — it delays the moment your page is permitted to begin, and every rendering metric that follows, Largest Contentful Paint included, simply starts later.
The same applies to crawlers, which spend the same requests on your plumbing instead of your content. And the measurement here is the optimistic one: this test runs from a server on a fast connection. A visitor on mobile data pays noticeably more for the identical chain.
Once you know the number, the fix is structural rather than clever. Trace the path in the redirect chain checker, find the rule that emits the first hop, and rewrite it to point straight at the final URL. One redirect stays; the rest of the measured delay is gone for good.
Frequently asked questions
- How much does a redirect slow down page load?
- There is no single number, which is why generic answers quote anything from 60ms to 500ms per hop. The real cost depends on where that server is, whether the connection has to be renegotiated, and how fast the redirect itself is answered. This test measures your URL specifically: each hop is timed, and the total is the delay a visitor waits through before the destination page even begins to load.
- Is one redirect bad for performance?
- One redirect is a real cost but usually a small one — often under 150ms, and unavoidable when a URL has genuinely moved. What matters is that it is a single hop. The damage comes from chains, where the same wait is paid two, three or four times over before anything renders.
- What is a good redirect time?
- Under about 150ms of total redirect delay is fast and roughly the floor for a single hop to a nearby server. Between 150 and 400ms there is real time to reclaim by flattening. Past 400ms the redirects are a measurable part of your load time, and on a slow mobile connection the same chain costs considerably more than the number measured here.
- Do redirects affect Core Web Vitals?
- Yes, through the front door. Every redirect hop happens before the browser can request the destination's HTML, so the delay pushes back the first byte and everything that follows — including Largest Contentful Paint. It doesn't change how fast your page renders once it starts; it changes when it is allowed to start.
- How is this different from a redirect chain checker?
- A chain checker answers where the URL goes and what status each hop returns. This test answers what that path costs in time, hop by hop, with the total a visitor waits. Same trace, different question — use the redirect chain checker to fix the structure and this one to justify the fix.
- Why is my redirect slower than the numbers I read online?
- Published averages are measured between well-provisioned servers on fast networks. Your chain may cross regions, hit a cold origin behind a CDN, renegotiate TLS on a protocol change, or pass through a rule engine that adds its own processing. That is exactly why measuring your own URL beats reading an average.
- Does flattening the chain really return the whole delay?
- It returns everything except one hop. Replacing a chain with a single 301 straight to the final destination keeps one redirect's cost and eliminates the rest — permanently, for every visitor and every crawler that touches that URL.