Sad kitten is sad

Link shorteners are harmful, they hurt the user experience and break the Web.

Link shorteners appeared as a consequence of the rise of Twitter. With a 140 characters limitation, sending full links over the micro blogging network was almost impossible. All you need to build your own URL shortener is a 30 lines PHP script and a 4 to 6 characters domain name. Many services launched, relying on providing analytics for a domain you don’t own to differ from the competition.

Update 201405271101: actually, link shorteners are older than Twitter even though the micro blogging service made them bloom like flowers. From HN discussion about this post:

No. The first extremely popular link shortener was TinyURL, and it launched in 2002, years before Twitter existed. Link shorteners became popular because URLs for some websites are extremely long and unwieldy, and are thereby difficult to type; they also have tons of punctuation, and are at danger of being mangled by various transports due to line wrapping, escaping, and character mapping.

Twitter becoming huge, spam and malware became a real problem for the company. To fight both of them, Twitter launched t.co, a URL shortener they apply on every tweeted link. Not only does t.co shorten links, it also check checks for the target site sanity and warns the visitor accordingly.

Applying t.co to every link posted on Twitter would have been OK if people did not keep using other URL shorteners, but they didn’t. The ability to chain services to push a link on Twitter led to some URL shortening madness that hurts the user experience and silently breaks the Web

Yesterday, I clicked on a bit.ly link someone had pushed to Twitter using Buffer to broadcast a link from Pocket. The Pocket to Buffer to Twitter workflow is a pretty common one, but this time, the madness went too far.

Let’s see what happens when you click on that link:

  1. In your Twitter feed, you click on a link that appears like the final destination.
  2. You’re actually sent to Twitter URL shortener t.co.
  3. t.co redirects you to j.mp, Buffer default URL shortener.
  4. Jump redirects you to pocket.co, Pocket URL shortener.
  5. Pocket.co redirects you to getpocket.com to get the initial link.
  6. Getpocket.com redirects you to bit.ly, the URL shortener that was initially used for your link.
  7. Finally, bit.ly redirects you to the original site.
  8. If you’re really out of luck, you fall on a landing page asking you to subscribe to the site, with a « access your article » link.
URL shortener Requests Latency
1 t.co 2 (DNS + HTTP) 200ms
2 j.mp 2 (DNS + HTTP) 400ms
3 pocket.co 2 (DNS + HTTP) 200ms
4 getpocket.com 2 (DNS + HTTP) 200ms
4 bit.ly 2 (DNS + HTTP) 400ms to 2s
5 your site 2 (DNS + HTTP) Depends
**TOTAL** **14** (DNS + HTTP) just to access your site main page (without CSS, Javascript and images) **1.8s to 3.4s** just for redirections

1.8 to 3.4 seconds are spent in redirects before you can access the page. For the record, Amazon says that 100ms of latency costs them 1% in sales, and Google found an extra .5 seconds in search page generation time dropped traffic by 20%.

I love spending 4 to 5 seconds staring at a blank page while I’m redirected in an endless loop. – No one. Ever.

This is both an extreme case and an « I’m (feeling) lucky » one.

You usually don’t control the company behind your URL shortener service. They can be overloaded. They can delete or lose your data without even telling you. They can disappear just like tr.im did a few years ago. Every time this happens, you lose a part of the return path to your link. It means your content becomes inaccessible.

In fact, when you’re using a URL shortener, you give away part of your content to that company. They can decide to build a paywall to your links, put your content into a frame so they can add advertisement to them, censor them if they don’t like what you publish… and I probably forget a few things.

I know this makes people very skeptical because the theory says a link on Twitter has a life expectancy of 24 to 48 hours, so let’s play the SEO card. All URLs shorteners don’t use clean 301 redirects. Some of them use 302 redirects so Google believe the redirection is only temporary. That way, the shortener actually gets all the juice your site should have got instead.

How to avoid breaking the Web

Indeed, there are a few ways to limit the madness. The first one is easy: when pushing a link on Twitter (or anywhere else), always post the expanded version of the link.

If you’re using Buffer, there is a settings tab that allows you to disable the URL shortening so only Twitter t.co will apply.

If you’re using Pocket, never use their « tweet this » feature, as there is no way to disable their 2 redirections (!) URL shortener. I may be wrong, but the 301 then 302 redirects look like some nasty black hat SEO tactics.

And indeed, the most obvious one: don’t use a URL shortener, or any Scoop.it like site when you post a link. Ever.

But…

Most massive link pushers will tell you their little brother will die from cancer if they don’t use a URL shortener.

Here’s why.

They use a URL shortener to track trafic and « engagement » to their content: how much clicks were generated from Twitter, Facebook, Linkedin… without an access to the site’s Google analytics. That’s because figures are more important than people who read their content. In other words: spam.

They use a custom URL shortener with their own domain because that’s what people see on Twitter so they can build their brand. They don’t really care about people actually reading what they tweet as long as they spread the love. In other words: spam

So let’s finish this way: there is no acceptable reason to use a URL shortener either on Twitter or anywhere else on the Web. There’s been a recent debate lately on how nofollow links were killing the Web. URL shorteners are worse.