Eliminate Redirect Chains
Cut unnecessary HTTP redirects that add a full network round-trip before the first byte of HTML.
Metrics
This technique can move up to 67% of LCP's share of the Lighthouse score.
This technique does not move TBT.
This technique does not move CLS.
This technique can move up to 67% of FCP's share of the Lighthouse score.
This technique can move up to 67% of SI's share of the Lighthouse score.
This technique does not move TTFB.
Overview
Each HTTP redirect adds at least one full network round-trip — 50–300 ms on a typical connection — before the browser receives a single byte of the actual page. A chain of two redirects adds 100–600 ms before HTML even starts downloading. Redirect chains are invisible in normal browsing but show up clearly in Lighthouse and WebPageTest as wasted time at the very start of the waterfall.
Impact grade, A+ to D: how much of the Lighthouse score this technique can move. Unaffected: TBT, CLS, TTFB.
The Problem
WordPress sites accumulate redirects from permalink changes, HTTPS migrations, plugin URL normalisation, and trailing-slash enforcement. A request for http://example.com/page might redirect to http://www.example.com/page/ then to https://www.example.com/page/ — three separate round-trips before HTML begins. On mobile networks with 150 ms RTT, this chain costs 450 ms before the first byte.
Performance Impact
LCP
100–500ms
HTML download and LCP image fetch both start sooner
FCP
100–600ms
each redirect eliminated removes one full network RTT
SI
100–400ms
all visual content appears sooner when HTML arrives sooner
Risk: Low
consolidating redirects is safe — just update the final destination
How it works
01
Audit existing redirects
Use Screaming Frog (free up to 500 URLs) or
curl -L -v https://example.com/urlto trace redirect chains. Identify chains of 2+ hops and map each to its final destination.02
Collapse chains to a single redirect
Instead of A → B → C, configure A to redirect directly to C. Update the source — whether an Nginx rule, Apache
.htaccess, or WordPress redirect plugin entry — to point to the final URL.03
Fix WordPress canonical redirect sources
WordPress automatically redirects non-canonical URLs (missing trailing slash, wrong case, HTTP → HTTPS). Set the canonical form in Settings → General (use https:// and choose www or non-www) and configure the web server to match — so WordPress never needs to issue a secondary redirect.
04
Update internal links to final URLs
Every internal link that points to a redirected URL costs a round-trip. After collapsing redirect chains, update internal links to point directly to final destinations — eliminating the redirect cost entirely rather than just shortening the chain.
Limitations
- Some redirects are intentional — login redirects, locale detection, A/B testing — and cannot be eliminated without changing the feature.
- Third-party redirect services (link shorteners, tracking URLs) add redirects outside your control — use direct URLs in internal content.
- CDN-level redirects happen before your origin server and must be configured separately in the CDN dashboard.
Common Mistakes
Fixing redirect chains in WordPress but not at the web server level
WordPress redirect plugins handle application-level redirects, but server-level redirects (HTTP→HTTPS, www→non-www) happen in Nginx or Apache config. Check both layers — a server redirect followed by a WordPress redirect still creates a chain.
Using 302 temporary redirects for permanent URL changes
302 redirects are not cached by browsers, so every visit incurs the round-trip cost. Use 301 for permanent URL changes — browsers cache 301s and serve the destination directly on repeat visits.
Need help applying this to your site?
Targeted fixes, not guesswork. We identify which techniques move the needle for your specific WordPress stack.
Start an Engagement