URL shortener speed and reliability shootout

With the rise of microblogging, URL shortening services have become extremely popular. And no wonder; just imagine sharing links on Twitter without one. Although some of these services have considerably more market share than others (we’re looking at you, Bit.ly and TinyURL), there are plenty of options out there.

One thing that has surprised us a bit here at Pingdom is that we haven’t seen any real numbers on how reliable and how fast these different URL shorteners are compared to each other. After all, adding a layer on top of the target URL (the direct link) means slower access and also adds a single point of failure, so these things should matter.

With this in mind, we decided to select a number of common URL shortening services and test two things:

How much overhead they add to accessing the target URL (extra load time).

What we tested

While some use them to get statistics, the main purpose of URL shortening services is to redirect you from a short alias to a target website, so this is what we focused our test on.

For each of the included URL shorteners we created a short URL for the same target URL. We used a rock-solid target URL, search.yahoo.com, which we consider to be one of the most reliable websites on the Internet. Our separate monitoring of that site confirms that it was available 100% of the time.

We then set up monitoring of each short URL, testing them once every minute during 30 days (starting July 18 and ending August 16). The tests were performed from several locations spread over North America and Europe. This was done using our Pingdom website monitoring service, which gave us both uptime and load time information. In short (no pun intended), it let us test how fast and reliable these URL shorteners are when it comes to their core service; redirecting your traffic.

Now on to the results!

Added overhead when accessing websites

By overhead we mean how much extra time the end user has to wait compared to the time it would have taken to access the target URL via a direct link, not going via the shortening service.

To get these numbers we simply compared the average load time for the target URL with the average time it took to access that site via the shortening service.

As you can see, there is quite a big difference between the services when it comes to how much overhead they add.

A few observations:

The three fastest services in the test are Is.gd, Bit.ly and Ow.ly.

The fastest service in the test, Is.gd, is more than five times faster on average than the slowest, Snipurl.

Bit.ly is 1.6 times faster on average than TinyURL.

None of the services add more than a second to the load time (on average).

Forwarding reliability (uptime)

Perhaps even more important than how fast these services are (many would argue a few hundred milliseconds in load time won’t make a huge difference), is how reliable they are. Once a short URL has been created, how much can you trust that it will work and keep redirecting to your target site?

Since uptime percentages can often feel somewhat abstract, we have also added how much yearly downtime it would be the equivalent to in the table here below. Please note that this is based just on the results of this 30-day test window and is only shown here for illustrative purposes. Downtime for websites can vary significantly from month to month.

The three most reliable services in the test are Ow.ly, Bit.ly and Su.pr.

Only one service had zero downtime during the time period: Ow.ly.

Five out of nine services had a 99.9% uptime or better, which we have to consider acceptable. In addition to the three mentioned above, this includes TinyURL and Is.gd.

There are bound to be glitches even for relatively simple services such as these. Bit.ly’s 99.98% uptime is the equivalent of failing once for every 5,000 clicks. In general, a 99.98% uptime is very respectable.

The overall score, crowning two “winners”

If we average the placement (1-9) of the shortening services in the two categories from above, we get the following list (the lower the score, the better):

Ow.ly: 2

Bit.ly: 2

Is.gd: 3

Su.pr: 3.5

TinyURL: 4.5

Twurl: 7

Snipurl: 7.5

Cli.gs: 7.5

Tr.im: 8.5

So, by these two simple criteria, Ow.ly and Bit.ly tied for “first place.”

Of course, there are many other factors to consider when picking a URL shortening service, but for the purpose of this test, this is what we ended up with when considering the speed and the reliability of the forwarding function of these URL shortening services (which has to be considered their main purpose).

Why it matters

Like it or not, URL shorteners are more popular than ever and we depend on them working properly.

For publishers (like bloggers) the reliability of these services is very important. If the URL shortener of their choice doesn’t work, they will lose traffic.

For end users, slow or broken links are a source of frustration.

We hope you found this report interesting. If you have any questions or comments, please feel free to add your thoughts to the comments (or email us).

A small note regarding the Diggbar: Originally we included the Diggbar in the test, but since it no longer functions as a regular URL shortening service we excluded it. For those interested, it added an average overhead of 429 milliseconds and had an uptime of 99.98% during the test period.

A note regarding how we counted downtime: For something to be considered down it had to take more than 30 seconds to load, or be completely inaccessible, or return an HTTP error code. We also always confirm errors from two different locations before we count them.

Didn’t know about ow.ly before, I tend to use is.gd since it’s the shortest one I knew of. I’ll probably continue using it, because I’ve had no problems, and it only narrowly lost out to ow.ly in your tests.

also, take into account that ow.ly is one character shorter than bit.ly, and in a non-scientific one shot test, ow.ly returned a 4 character key and bit.ly returned a 6 character key, making the ow.ly url 3 characters shorter in total

Disregarding for a moment that your methodology is pretty idiotic (if not ignorant) I’ll tell you why is.gd is fast. Because it’s a new copycat service and the number of URLs to search through in the DB are much smaller. Snipurl and Tinyurl have been around for over eight years now. Like tr.im, maybe others will go down too. It’s easy to start a service but tough to hold on to it. I have thousands of my URLs with Snipurl and trust them the most. Tiny is good when I don’t need to track or do anything, otherwise Snipurl is top dog. All other copycats can come and go.

I use 3.ly, which can be customized (http://3.ly/customization). 3.ly is the shortest URL shortener I have found. So far, I don’t know of any of my links not working. With micro-blogging services being all the rage, it’s very important to be able to squeeze as much information into one place as you can. Of course, you want those URLs to be timeless as well, especially in my industry where ideally your work lasts ‘forever’.

I use Bit.ly. I like the HootBar, but until HootSuite adds the links stats like Bit.ly’s got my vote – there is a reason they’re No. 1. Also, the HootSuite redesign I find harder to use than the old version. It takes too many steps to complete simple tasks.

I’ve been using foxyURL because of the convenient Firefox addon. I wish you had tested it as well. OTOH, I understand the criticism of Matt Ril. OTOH, almost all of my uses require the link to be good for just a few days. Here’s this page’s foxyURL: http://foxyurl.com/slD

Now Twitter is adding his own tracking system, so before going to the short url, the link pass through something like http://twitter.com/link_click_count . This increases a lot the overhead. In my country (Peru) with a very decent connection I see 1 second of time overhead to the original link.
I made my own calculations using Hammerhead tool from Steve Souders but it will be very nice if you can offer your own results.

@matt ril
Do you not know how a database w/ indexing works? clearly not, since in your scenario tinyurl, snip and bit would be all on the losing end. I dont know of any Db services that search for a key with a linear search, but keep on defending your Is.gd friends to the death . . . .