Redirects Don’t Hurt Performance — Blocking Paths Do

Redirects are often treated as a web performance anti-pattern. Tools like PageSpeed and Lighthouse reinforce this perception by flagging redirects as something to avoid. Over time, this turns into a simplified rule: “redirects are bad”.

The problem isn’t the warning itself, it’s the lack of technical context behind it.

When we understand what redirects actually cost, the conversation becomes clearer, more precise, and far less dogmatic.

What PageSpeed Is Really Penalizing

Redirects are not inherently slow.

What hurts performance is adding extra network round-trips in the critical path before the browser receives HTML.

This usually happens when:

• Multiple redirects are chained together

• Redirects occur before the HTML response

• Redirect decisions depend on external I/O (APIs, CMS lookups, databases)

Each redirect introduces another request–response cycle. These hops accumulate latency before rendering can even begin.

The result is measurable impact on:

• TTFB, due to delayed server responses

• LCP, because HTML delivery is postponed

• Mobile experience, where latency is amplified

A Realistic Next.js Scenario That Creates Multiple Hops

A common pattern in modern applications combines dynamic redirects with authentication checks.

For example:

1. A route is intercepted by middleware

2. A CMS lookup determines a redirect

3. The request re-enters middleware

4. Authentication logic triggers another redirect

Before any HTML is returned, the browser has already followed multiple hops.

Even when running on the Next.js edge network, this flow:

• increases TTFB

• indirectly affects LCP

• degrades mobile latency

The framework isn’t the issue. The delivery path is.

When Redirects Are Practically Free

Redirects stop being a performance concern when they are:

• Resolved at the edge, close to the user

• Single and deterministic, not chained

• Permanent (301 / 308), allowing aggressive browser caching

• Independent of heavy external I/O

In these cases, the redirect cost is paid once, or not at all, and disappears from the critical path on subsequent navigations.

Conclusion

Redirects are not performance villains. They are essential for SEO, product evolution, and large-scale applications.

They become a problem only when they block delivery, create unnecessary hops, or depend on slow decisions at request time.

Understanding this distinction prevents fragile architectures and replaces fear-driven decisions with reliable, measurable solutions.