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).
- How reliable they are, i.e. their uptime (availability).
The services included in this test are: Bit.ly, TinyURL, Ow.ly, Is.gd, Su.pr, Snipurl, Cli.gs, Tr.im and Twurl.
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.
| URL Shortener | Uptime | Estimated downtime in a year (hours) |
|---|---|---|
| Ow.ly | 100.00% | 0.0 |
| Bit.ly | 99.98% | 1.8 |
| Su.pr | 99.97% | 2.6 |
| TinyURL | 99.96% | 3.5 |
| Is.gd | 99.94% | 5.3 |
| Snipurl | 99.87% | 11.4 |
| Cli.gs | 99.60% | 35.0 |
| Twurl | 99.53% | 41.2 |
| Tr.im | 99.10% | 78.8 |
A few observations:
- 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.
(If you find yourself often having to convert between uptime percentages and monthly/yearly downtime, you may find this uptime/downtime conversion cheat sheet helpful.)
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.
