Skip to main content
miji.be

Redirect Caching

A mechanism in which browsers and CDNs store redirect responses for a certain period and skip querying the origin server on later visits.

Oct 31, 2026 / About 1 min read

Redirect

Redirect caching is a mechanism in which browsers and CDNs store redirect responses (3xx responses) and, on subsequent visits, go directly to the redirect destination without querying the origin server. For URL shorteners, it is a design element involved in achieving both performance and click measurement.

RFC 9110 defines 301 (Moved Permanently) and 308 (Permanent Redirect) as responses that a cache may reuse with a heuristic expiration time even without explicit cache directives (heuristically cacheable), and does not define 302 (Found) and 307 (Temporary Redirect) that way. RFC 9111 leaves the length of the heuristic expiration time up to the cache. While a cached 301 is in use, requests do not reach the origin server and latency goes down, but the URL shortener cannot count those clicks. Responses with 302 or 307 go through the origin every time unless Cache-Control or a similar header specifies otherwise, which makes it easier to record clicks on the server side.

Caching behavior can also be controlled with the Cache-Control header. Under RFC 9111, a response with no-store is not stored in the cache, and a response with max-age=0 is treated as stale right away even if it is stored, so in principle it must be validated with the origin before reuse. Conversely, for redirects that do not need measurement, setting a TTL such as public, max-age=3600 and having the CDN layer cache them can reduce the load on the origin.

Some services also take redirect caching at the CDN into account. CloudFront's documentation explains that it caches 3xx responses according to the distribution settings and the response headers (as of October 2026). While a response cached at the edge is being returned, requests do not reach the origin, so click measurement comes to depend on edge logs.

Designing a URL shortener calls for a Cache-Control design that weighs the trade-off between recording clicks and performance, based on how redirect caching behaves. This means using 301 and 302 for different purposes and controlling the cache TTL.

Was this article helpful?

Related Terms

Cache

A temporary storage mechanism that saves previously fetched data for faster subsequent access. Browser cache and DNS cache are common examples.

TTL

Time to Live - a value that specifies how long data should be cached or considered valid before being refreshed.

301 Redirect

A permanent HTTP redirect that tells browsers and search engines the resource has moved permanently to a new URL.

CDN

A network of geographically distributed servers that deliver web content from the location nearest to the user. Improves speed and reliability.

Redirect Latency

The delay incurred during a shortened URL's redirect process. A critical performance metric that directly affects user experience and conversion rates.

Client-Side Redirect

A redirect executed by the browser using HTML meta tags or JavaScript, after the initial page has been partially loaded.

Related Articles

How Redirect Chains Impact Web Performance - Speed Optimization for Short URLs

Quantitative analysis of how short URL redirect chains affect Core Web Vitals and page load speed. Covers redirect hop optimization, edge redirects, and HTTP status code selection for maximum performance.

301 vs 302 Redirects - Choosing the Right Type for Short URLs

Understand the differences between 301 and 302 HTTP redirects. Learn how each type affects SEO, analytics, and performance for short URLs.

How URL Shorteners Work - The Technical Side of Redirects

Discover the technical mechanics behind URL shortening: hash generation, database lookups, HTTP redirects, and more. Includes HTTP response examples and base-62 encoding calculations.

Put the terms to work

Shorten a URL for Free