Every short link is a detour. Somebody taps it, their browser asks the shortener where to go, the shortener answers, and only then does the browser start on the real page. People ask whether that detour is long enough to matter. We hadn't measured it either, so on 27 October 2026 we did.
The short answer: it depends far more on which shortener you use and where your reader is than on short links as such. The same tap cost 69 milliseconds on one service and just over a second on another, from the same desk.
What we did
We made a link to the same Wikipedia page on six shorteners that need no account (TinyURL, is.gd, v.gd, da.gd, spoo.me and ours), and took five live links from services that do: a Bitly link, QR codes from QR Code Generator (qrco.de), QR Stuff (qrs.ly) and Scanova (scnv.io) that those companies show on their own sites, and a YouTube youtu.be link. Only the first hop was timed, the shortener's own answer, so it didn't matter where each link went next.
Then we tapped each link 20 times from three places at once: a home fibre line in Chennai, India, a server in Lauterbourg in eastern France, and a server in St. Louis in the middle of the United States. Each tap was a fresh connection, like a first click from a new reader: name lookup, connection, encryption, the request, the answer. Two seconds' pause between rounds. Afterwards we asked each link ten more times over one open connection, which shows how long the shortener itself takes to think once the connection costs are gone.
The numbers
Median time for the first hop, in milliseconds. "New" is a fresh connection each time (what a reader gets); "open" is a connection already open, which is roughly the shortener's own thinking time.
The slow taps matter as much as the typical one. One tap in ten took longer than 1,853 ms on b59.link from Chennai, 1,206 ms on scnv.io from Chennai and 1,104 ms on qrs.ly from France. The worst single tap was 2.5 seconds, also ours from Chennai.
Why the spread is so wide
The numbers fall into three groups, and the group tells you more than the brand does.
Answered next door. qrco.de and TinyURL were under 100 ms from all three places, and once the connection was open they answered in 8 to 23 ms. Both sit behind a network with servers in many cities, and the answer for a link is kept on the server nearest the reader. Nothing has to travel far.
Front door next door, answer from far away. is.gd, v.gd, spoo.me, Bitly and qrs.ly also connected quickly: from Chennai the encrypted connection was ready in 50 to 90 ms, spoo.me in about 200. But the answer still had to come from the company's own servers, and even on an open connection it took 290 to 420 ms to arrive in Chennai. A nearby front door doesn't help if the person with the key lives on another continent. qrs.ly is slow from everywhere, around 400 ms on an open connection even in St. Louis, so that time is spent inside the service, not on the road.
One building. da.gd, Scanova's scnv.io and b59.link each answer from one region. da.gd is quick in France (73 ms) and slow in Chennai (707 ms); scnv.io was quickest in St. Louis and slowest in Chennai. For these, the connection itself is the cost: just opening the encrypted connection to b59.link from Chennai took a median 573 ms before the question was even asked.
Does half a second matter?
Google's web.dev guide counts redirect time inside Time to First Byte, the wait before the first byte of the real page arrives, and calls 0.8 seconds or less good and more than 1.8 seconds poor. A first hop of 854 ms or 1,045 ms spends that whole budget before the real page has even been asked for. A 70 ms hop is lost in the noise.
Two things make it worse in real life. Our three places were on fixed lines; a phone on mobile data, which is who scans a QR code, usually takes longer to open each connection. And hops add up: a short link that points to another short link, or to an http:// address that forwards to https://, which forwards to www., pays a connection for each one.
Time your own links
1. Know where your readers are. Your analytics will tell you the countries. A shortener that is quick in New York can be slow in Mumbai, as ours is.
2. Time the first hop from there. If you or a colleague are in the same country, this one line asks the link once without following it and prints the status and the seconds taken. Run it five or ten times and look at the middle value:
3. Count the hops. Paste the link into our redirect checker. It lists every hop with its status code and milliseconds. The checker runs in the United States, so its times are what a US reader gets; use it for the number of hops, and step 2 for your readers' timing.
4. Point the short link at the final address. Full https://, with or without www. exactly as your site serves it, no second shortener in between. Each hop you remove saves a whole connection.
5. If the reader is far from every option you like, a plain link or a plain QR code with your own address skips the detour entirely. You lose the click count and keep the speed.
Where we stand
We didn't enjoy writing the b59.link row. Our links answer from the United States, so they are quick for US readers and slow for readers in India: a median 854 ms from Chennai, with one tap in ten over 1.8 seconds. In eastern France, 358 ms. If most of your readers are in Asia today, TinyURL and qrco.de answered faster than we did, and we'd rather you knew that. Answering closer to readers outside the US is now on our own list, and we'll run this same test again when it changes.
Paste any short link and see each hop, its status code and how long it took. Nothing is stored.
Check a link's hopsHow we measured, and the limits
27 October 2026, 05:40 to 06:00 UTC. curl 8.x with a phone browser's user agent, redirects not followed, 15-second limit, no failed requests. 20 taps per link per place on fresh connections (220 per place), then 11 requests on one connection, of which we used the last 10. Medians and the 90th percentile of the 20 taps. Places: home fibre in Chennai, India; servers in Lauterbourg, France, and St. Louis, Missouri. The six links we made all point to the same Wikipedia page; the Bitly, qrco.de, qrs.ly and scnv.io links are sample codes from those companies' own sites, and the YouTube link is a well-known video, so their destinations differ, which doesn't affect the first hop. v.gd answers with a preview page (200) rather than a redirect, so a reader also has to click through it; we timed the page only. One day, three places and fixed lines: read the numbers as how these services compare from those places, not as what every reader gets. Time to First Byte thresholds: web.dev, Time to First Byte (TTFB). See also: 301 or 302 for a short link.
