The 260ms Nobody Caches: 88% of WordPress Sites Redirect an http Visitor Before Serving a Byte in 2026

Updated October 2026

We probed 1,000 WordPress sites from our own scan archive on 2 October 2026. On 816 of the 919 that answered, typing the bare domain produced a redirect before any page was served, at a median cost of 260ms. Per Google’s web.dev guide to Time to First Byte, last updated 18 November 2025, redirect time is one of the phases TTFB is made of, so that 260ms lands inside the metric everyone is trying to reduce. The comparison people expect here is which caching plugin returns a page fastest. The more useful one is what the visit costs before any cache is consulted at all. This study measures only the first navigation request to a site’s home page.

Quick Summary: What a Hop Costs and Who Pays It

How This Was Measured, and Six Things It Cannot Settle

The limitations come before the results, because two of them change how the numbers should be read.

The sample is every unique host in the xSpeed Scan archive that our scanner identified as WordPress, 1,981 of 2,965 reports covering 30 August to 2 October 2026. From those we drew a random sample of 1,000 with a fixed seed and probed each one twice, once at http://host/ and once at https://host/, following up to ten redirects with a desktop browser user agent. A third probe took the other www form of the same hostname over https. Every timing figure comes from curl’s own counters inside a single request: time_redirect is the time spent on all redirection steps, time_starttransfer is the time to the first byte of the final response.

Here is what that design cannot support.

1. The absolute milliseconds are an upper bound. The prober runs in one cloud container and reaches the internet through an HTTP CONNECT proxy, so every connection carries overhead a visitor’s browser does not. Treat the shape of the distribution as the finding and the milliseconds as a ceiling.
2. The milliseconds are also noisy per site. 487 hosts were probed twice minutes apart. Time to first byte moved by a median of 232ms between the two runs, and by 2,052ms at the 90th percentile. One site’s number is inside that noise. A median across 816 is not.
3. The hop count, by contrast, is stable. The two runs returned an identical redirect count on 439 of 443 hosts that answered both times, which is 99.1%.
4. One geography, one moment. Every probe left from the same place within one hour. A site that redirects by country or by device may behave differently for your readers.
5. Home pages only. Nothing here measures a deep URL, and category or tag routes often carry their own trailing-slash rule.
6. Cache state is borrowed. When we split sites by whether the page came from cache, that label comes from the scan report for the same host, graded earlier and against the canonical https URL. It describes the site, not that exact request.

What the design does well is isolate one thing. Both halves of the measurement sit inside the same request, so the hop and the response are timed by the same clock, on the same connection path, within milliseconds of each other.

The Redirect Tax Test

The framework is two commands and one subtraction, and it works on any site in about ten seconds.

# 1. The entry a visitor actually types
curl -sL -o /dev/null -w 'hops=%{num_redirects} redirect=%{time_redirect} firstbyte=%{time_starttransfer}\n' \
  http://yoursite.com/

# 2. The URL that eventually answered
curl -s -o /dev/null -w 'firstbyte=%{time_starttransfer}\n' \
  https://www.yoursite.com/

Your redirect tax is redirect from the first command. Your redirect share is that number divided by the first command’s firstbyte. Run the second command to confirm the destination answers directly, because a chain that ends on a URL which itself redirects is the case that turns one hop into three.

Three things make this falsifiable rather than rhetorical:

• The numbers come from the transfer library rather than from a stopwatch wrapped around the whole command.
• Both halves are measured inside one request, so network conditions cannot drift between them.
• Anyone can re-run it against the figures published below, from their own connection, today.

What the test cannot do is tell you which layer emitted the 301. A hop can come from the web server, from a WordPress plugin, from an edge rule at your CDN, or from a host-level setting you never see. The test gives you the cost and the destination, and locating the source is a separate job that starts with your server configuration rather than your plugins.

Nine in Ten Sites Redirect an http Arrival

The https column is the reassuring one and it is also the trap. A modern browser tries https first on most navigations, so for the majority of visits there is no hop at all. The 88.8% figure describes a narrower and very persistent set of arrivals: a link in an old email, a QR code printed last year, a hardcoded http:// link in someone else’s blog roll, a bare domain typed into an address bar that has never seen the site before, and anything arriving from a client that does not upgrade.

Where do those hops land? Overwhelmingly in one place.

So the redirect tax on WordPress is not a tangle of competing rules. It is one hop, doing one job, on nineteen sites out of twenty.

The Hop Costs a Median 260ms, and a Third of the Wait

Across the 816 redirecting sites the hop cost a median 260ms, with a quartile range of 140ms to 540ms and a 90th percentile of 1,098ms. As a share of the whole wait for the first byte, the median hop was 32.9%, the lower quartile 23.4% and the upper quartile 39.8%.

Two comparisons give that number meaning. Our own 22 September study of when a caching plugin is worth installing measured a 192ms median first-byte time on WordPress sites already serving from cache, and found 48.4% of WordPress sites with under 100ms of headroom left for a page cache to take. Against those two marks, 61.8% of redirecting sites spend more on the hop than a well-cached site spends on the entire response, and 92.6% spend more than 100ms.

The second comparison is Google’s. Per Chrome’s Lighthouse documentation for the “Avoid multiple page redirects” audit, a page fails only when it has two or more redirects, and the same page notes that the extra network trip “can delay the loading of the resource by hundreds of milliseconds”. Only 1.8% of the sites we probed cross that threshold. The common case, one hop costing a median quarter of a second, passes the audit cleanly.

A Cache Hit Does Not Pay the Toll

Splitting the redirecting sites by the cache evidence in their scan report separates what caching reaches from what it does not.

A cached site answers its own page in roughly half the time of an uncached one, which is the result our 958-site study reported last month in different terms. The hop in front of it barely moves. On a site that has done everything right at the application layer, the redirect still adds a median 220ms, and it adds it to a number the cache has already pushed as low as it can go.

That is the whole argument of this piece in one row. The cache cannot see the hop. The hop runs first, is answered by a layer the plugin does not control, and returns a response that contains no page at all.

The Wrong www Form Costs Six Times More

The third probe is the one we did not expect. Taking each sampled host and flipping its www prefix, then requesting that form over https, produced a redirect on 751 of the 784 pairs where both forms answered, and 747 of those landed on the canonical host. The median cost was 1,718ms, against 260ms for the plain scheme upgrade.

The reason is visible in the connection timings. On the http:// entry, the first request carries no encryption, so the redirect arrives after a TCP connection alone and only the second request negotiates TLS. On the wrong www form, the first request negotiates TLS with one hostname, receives a 301, and then negotiates TLS again with another. Median TLS handshake time on that first connection was 716ms. A hop that crosses a hostname boundary over https costs two handshakes rather than one, and the difference between the two cases is almost entirely that.

A second number from the same probe is worth stating plainly: 208 of the 1,000 alternate forms did not answer at all, 163 of them failing to complete a connection. The most likely explanation is a certificate that covers one form and not the other, though we cannot confirm the cause from outside.

Why Neither Instrument Reports This

Our own scanner saw a redirect on 113 of 1,981 WordPress reports, which is 5.7%. That is not a contradiction of the 88.8% figure. It is a different question. The scan reports the chain for the URL it was handed, and almost every URL submitted to it is already the canonical https address, so the hop has been paid before the scanner is involved.

There is a scoring point in this worth being honest about, since it is our rubric. Check D6, “Clean redirect chain”, is worth 2 points of the 30 available in the server response dimension. A site that adds a second to every http arrival loses at most those two points, and a site handed its canonical URL loses none. We also confirmed, across the 1,506 reports in the archive carrying both a desktop-graded and a mobile-graded view, that D6 returned identical points in both on every single one. That reproduces at a larger sample what our two-device study found on 30 September, and it means the redirect figure can be read off either view of a report.

Where Our Own Sites Land

Knowledge matrix rules mean we publish our own numbers in both directions, including the one that flatters us and the one that does not.

Sites running our plugin redirect an http arrival less often, by 8.4 points. When they do redirect, their hop is 57ms slower at the median. Both are published here under the same caveat: these groups were not assigned, sites choose their own plugins, and nothing in this data supports a causal reading in either direction.

Our own marketing site is in the majority. Requesting http://xspeedcache.com/ on 2 October 2026 returned one hop costing 364ms, a third of its 1,091ms first byte, and https://www.xspeedcache.com/ returned a hop costing 513ms. We measure other people’s redirect tax and we pay one.

Finding the Hop Across Twenty-Five Client Sites

If you manage one site, the fix is a configuration change you make once. If you manage twenty-five, the problem is that the hop is invisible from inside WordPress, so there is nothing in any dashboard that tells you which sites have it.

Three things make it tractable at scale:

• The test scripts cleanly. Both numbers come out of one curl invocation, so a loop over a host list produces a ranked worklist in about a minute.
• xSpeed Scan gives you something to send. It is free, needs no account, and reports check D6 for any URL you hand it, which produces a shareable report per site rather than a terminal buffer.
• The fix usually belongs to the host. Where the hop turns out to be a server-level redirect rather than a plugin rule, it is not yours to make from inside WordPress at all.

That last case is where we recommend xCloud, which is ours: xCloud and WPDeveloper are both Startise companies. Redirect rules, HSTS headers and certificate coverage for both hostname forms are host-level settings, and a managed host that exposes them is the difference between a five-minute change and a support ticket. Our own server compatibility notes cover what varies between nginx, Apache and LiteSpeed here.

xSpeed Cache itself does not claim this fix. It serves cached pages as static files before PHP starts, which is what makes the cached response fast, and that is exactly why it is downstream of the hop. The honest division of labour is that your host or your edge removes the redirect, and the cache makes everything after it quick. The free tier covers the page cache, browser cache headers and minification with no time limit, and the 80-capability comparison records which tier every feature ships in rather than only whether it exists.

Mistakes People Make With Redirects

• Treating the canonical URL as the entry point. The URL in your sitemap is not the URL in a 2019 forum post. Test the forms people actually arrive on.
• Chaining a scheme upgrade onto a host change. http://site to https://site to https://www.site is two hops where one would do. Send the first redirect straight to the final URL.
• Fixing it in WordPress. A plugin-level redirect still boots PHP. A server-level or edge-level rule answers without touching the application.
• Forgetting the certificate. A redirect from the other www form over https needs a certificate valid for that form, or the visitor gets a warning instead of a hop.
• Assuming a CDN removes it. Our CDN study found three of five Cloudflare sites still sending page requests to the origin. An edge that is not answering pages is not answering redirects either.
• Reading one measurement as truth. Our own repeat probes moved by a median 232ms. Run the test three times before you believe a difference.

Frequently Asked Questions

I fixed my redirect and my PageSpeed score did not move. Why?

Lighthouse scores the final URL after following redirects, and its redirect audit only fails at two or more hops. One hop is invisible to the score and visible in field TTFB. That gap is also why our lab-against-field study keeps finding the two disagree.

Is a 301 faster than a 302?

Not on the first visit. The difference is what the browser caches afterwards. A 301 is permanently cacheable so repeat visitors may skip the hop, a 302 is not. We saw both in the sample and the timing difference between them was not separable from noise.

My TTFB looks fine in my own testing but Search Console disagrees. What am I missing?

Most local tests hit the canonical https URL directly. Field data includes every arrival, redirects included, because per web.dev redirect time is one of the phases TTFB is composed of. Our guide to reducing WordPress TTFB covers the rest of the gap.

Does HSTS remove the hop completely?

For returning visitors, yes. An HSTS header tells the browser to rewrite http:// to https:// internally on subsequent visits, so no request leaves the machine. The first visit still pays, unless the domain is on the HSTS preload list.

Should I use www or no www?

Either, consistently. The cost is in having both answer with a hop between them over https, which we measured at a median 1,718ms. Pick one, serve a certificate covering both names, and redirect the other.

I moved hosts and my redirect tax appeared out of nowhere. What changed?

Redirect rules frequently live in the server configuration rather than in WordPress, so they do not travel with a migration and the new host supplies its own. Our guide to what silently changes after a host move covers the full checklist.

Can a caching plugin cache the redirect itself?

Not usefully. The 301 is produced before WordPress loads on most configurations, so there is no page for a page cache to store. What can hold it is the browser, through a cacheable 301, and the edge, through a CDN rule.

My site is on Cloudflare. Does the hop still cost me?

Yes, though usually less. The redirect is answered at the edge rather than at your origin, which shortens it. Our sample’s cache-hit group still paid a median 220ms.

How much of my LCP is this?

Less than people assume, which is the uncomfortable part. Our cache ceiling study found 93.4% of failing WordPress pages still fail Largest Contentful Paint with the entire server response removed. Removing the hop is worth doing and it will not rescue a page whose problem is after the first byte.

I run 25 client sites. What is the fastest way to find the bad ones?

Loop the Redirect Tax Test over your host list and sort by redirect time. The sites with a hop over 500ms were 28.1% of our sample, and they are where the minutes go. The agency use cases page covers the fleet-level view.

Does a trailing-slash redirect cost the same?

In our sample, path-level redirects were 3.1% of first hops and they behaved like any same-host hop, costing one extra round trip without a second handshake. The expensive hops were the ones that changed hostname over https.

What is the single number I should write down?

Your redirect time as a share of your first-byte time. Below 10% it is noise. Above 30%, which was the median in our sample, the hop is a bigger line item than anything a page cache can still win, and our browser cache documentation is the next place to look rather than a new plugin.

Conclusion: Fix the Entry Before You Tune the Cache

A page cache is measured on how fast it answers a request. This study is about the request before that one, which on 88.8% of the WordPress sites we probed exists, costs a median 260ms, and is answered by something a caching plugin never sees.

What to do this week:

1. Run the two-command Redirect Tax Test on your home page and write down the share.
2. Run a free scan and read check D6 against what you measured.
3. If both www forms answer over https, pick one and fix the certificate before the redirect.
4. Move any plugin-level redirect into the server or the edge, where it answers without booting PHP.
5. Then tune the cache. xSpeed Cache is free for the page cache, browser cache headers and minification, with Pro from $29 a year at the founding price and a 14-day money-back guarantee. The free and Pro split and the full pricing are both public.

If you run this test and get a result that contradicts ours, we would rather hear it than not. The archive behind these numbers grows every day, and the same query in December is a different study.