Where redirect latency actually comes from

The anatomy of a redirected click

A click on a short link is four steps: resolve the short hostname in DNS, open a TLS connection to the redirect server, receive the redirect response, then repeat the whole thing for the destination. Only the third step involves the shortener's own code, and in a well-built system it is the fastest part.

DNS is usually the biggest variable

If the visitor's resolver has never seen your short domain, the lookup walks the DNS hierarchy and can take a hundred milliseconds or more. If it is cached, it costs nothing. That is why a link's first click in a new region feels slow and the next thousand do not.

You influence this with TTL. A very short TTL gives you fast failover when you change providers but forces frequent lookups. A moderate TTL of an hour is a reasonable default; drop it to a few minutes for the day of a planned migration, then raise it again.

TLS handshakes cost more than the lookup

A fresh TLS connection needs a round trip or two before any HTTP happens. Over a mobile network with 60ms of latency, that is real time. Providers reduce it with session resumption and by terminating TLS close to the user, which is the main practical argument for an edge network: it is not that the lookup is faster, it is that the handshake is shorter.

The lookup itself should never be the bottleneck

Resolving a slug to a destination is a single key lookup. Any sane implementation serves it from memory, with the database as a cold path. If your redirects are slow and the cache is warm, the problem is almost certainly network topology or a chain of redirects, not the query.

Redirect chains are the silent killer

Each extra hop repeats DNS, TLS and HTTP. A link that goes shortener to marketing platform to campaign URL to a locale redirect can easily spend half a second before the browser starts fetching anything the visitor can see. Every chain also risks dropping query parameters or the referrer.

Audit this with curl and follow redirects verbosely. Count the hops. If there is more than one, point the short link at the true final URL and delete the intermediate steps.

Where the destination site adds its own delay

People blame the shortener for slowness that belongs to the landing page. Once the redirect is delivered, everything after it — a slow origin, a heavy page, a client-side framework that renders after fetching — is the destination's problem. Measure the two separately before you conclude anything.

How to measure honestly

Time the redirect on its own with a request that does not follow the Location header, from several regions, at several times of day. Compare that with a request to the destination directly. The difference is what the short link actually costs you, and for most platforms it lands in the tens of milliseconds.