HTTP Redirects

Protocol

Server responses (301, 302, 307, 308) that tell clients to request a different URL. Each redirect adds a full round trip. Redirect chains (A→B→C) multiply the latency penalty and hurt Core Web Vitals.

Updated Mar 9, 2026

Full Explanation

HTTP redirects are simple but expensive. A 301 or 302 response contains a Location header pointing to a new URL. The client has to make an entirely new request to that URL—DNS lookup, TCP handshake, TLS negotiation, and all. One redirect easily adds 100–300ms to page load time.

In CDN setups, redirects commonly happen for: HTTP-to-HTTPS upgrades, www-to-non-www normalization, vanity URLs, and geographic routing. The problem compounds when you chain them: HTTP → HTTPS → www → final URL = three extra round trips before content loads.

Best practice: eliminate redirect chains by going directly to the final URL. Handle HTTP-to-HTTPS at the CDN edge, not the origin. Use 301 (permanent) for SEO-friendly redirects that browsers can cache, and 307/308 for temporary redirects that preserve the request method (important for POST requests).

Try the interactive Request Flow animation in the course to see how redirect chains add latency to each step of the request lifecycle.

Examples

Eliminating redirect chains in Nginx:

# BAD: two separate redirects (chain)
server {
    listen 80;
    return 301 https://$host$request_uri;  # redirect 1
}
server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;  # redirect 2
}

# GOOD: single redirect to final destination
server {
    listen 80;
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

Checking for redirect chains:

curl -sIL https://www.example.com/ 2>&1 | grep -E "(HTTP/|Location:)"
# HTTP/2 301  Location: https://example.com/
# HTTP/2 200

Video Explanation

Frequently Asked Questions

Server responses (301, 302, 307, 308) that tell clients to request a different URL. Each redirect adds a full round trip. Redirect chains (A→B→C) multiply the latency penalty and hurt Core Web Vitals.

Eliminating redirect chains in Nginx:

# BAD: two separate redirects (chain)
server {
    listen 80;
    return 301 https://$host$request_uri;  # redirect 1
}
server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;  # redirect 2
}

# GOOD: single redirect to final destination
server {
    listen 80;
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

Checking for redirect chains:

curl -sIL https://www.example.com/ 2>&1 | grep -E "(HTTP/|Location:)"
# HTTP/2 301  Location: https://example.com/
# HTTP/2 200
Previous Term HTTP/3
Next Term Image Optimization
Back to Glossary