I’ve found that one of the best things you can do for your website is host as much of it as possible from a Content Delivery Network, or CDN. For websites I manage, I make sure that at least all media items are served from a CDN. This ensures speed, response time and flexibility when moving domains.
There are quite a few CDN services available right now, some of them coupled with hosting services.
In this review, I’m going to put CDN77 through its paces. On paper, CDN77 looks like a viable – if not better – alternative to Amazon’s Cloudfront. So let’s see how it stacks up.
- Speed – It’s really fast. Scroll down for the full speed test details.
- Ease of setup – Setting up CDN77 on your site couldn’t be easier or faster.
- Custom care – the support is top notch.
- Lack of complex rules and customizations – forget trying to fine tune your resources any way you like. CDN77 is best suited to casual users who want all the complicated stuff taken care of.
The Bottom Line
It has proved to be faster by quite a margin, cheaper, I felt at ease using the interface, and support was simply fantastic. I highly recommend giving CDN77 a try if you’re setting up a new project – I’ve been very happy with them so far!
CDN77 – First Impressions
Actually, since Amazon offers so many services the AWS console is overwhelming, whereas CDN77’s control panel is much simpler.
It all started with a surprisingly quick sign up – name, email, password, press of a button and you’re in.
Compared to the Amazon AWS signup page, which has multiple steps, CDN77 is a breath of fresh air.
As I mentioned, the backend is much simpler as well. It features four main pages: Dashboard, CDN, Reports and Support. Initially, you’ll spend most of your time in the CDN section where you can set everything up (more on this later).
While I could think up better visuals, what is a lot more important is the structure and clarity of the layout. It is easy and fast to navigate and what’s what is very clear.
Setting Up CDN77
If you know how a CDN works and what you need to get going it’s a simple affair. If you don’t, there’s an excellent Getting Started guide and 24/5 chat support.
Here’s how I went about testing the service:
Step 1: Create CDN Storage
This is actually an optional step. If you already have your files set up somewhere, like your own host, or Amazon S3, you could choose to serve them from there. If you would like to use CDN77’s servers, you need to create storage, and define a label and the datacenter location.
You need to hover over “Show” beneath the connection credentials to see your FTP details, which is a super helpful shortcut. You can then start adding files to your CDN77 storage.
Step 2: Create New CDN Resource
By creating a new resource in CDN > CDN Resources, you can tell CDN77 where your files are located. The main option here is the “Content Origin.” If set to “My Source,” you’ll need to paste the URL of the root file location into the next field.
Initially, I set CDN77 up to work with my Amazon S3 bucket. If you’d like to do the same, simply paste the URL of your bucket in the origin field.
If you’re using CDN77 to store your files, select the storage you’ve created in step 1 and everything will be handled for you by CDN77.
Step 3: Use your CDN URL
As you can see at the top of the screenshot above, each CDN resource has a URL, something like: CDN URL: xxx.rsc.cdn77.org. You’ll need to use this URL for your assets. If you are using CDN77 to host your files and you’ve uploaded an image to
www/image.jpg you’ll need to refer to this image with the CDN URL:
If you are using Amazon S3 or you are hosting the files yourself, the origin you gave when creating the CDN resource will be the root folder for the CDN URL. If you’ve uploaded a file to
http://yourbucket.s3.amazonaws.com/test/image.jpg you’ll need to refer to it as
CDN77 integrates well with major CMS systems. Their Getting Started guide lists a total of eight, including WordPress, Drupal, Joomla and Magento. WordPress integration is achieved via the W3 Total Cache plugin. Take a look at the detailed guide for more information.
If you would rather use WP Super Cache there’s a guide for that too.
One of the most important factors when choosing a CDN is its speed. I tested CDN77 in various scenarios with a number of tools. Before we move on, I want to stress that these were all casual tests, which may not reflect the actual speed of CDN77 for everyone using it. That said, the general trend points to a clear conclusion, which I will share once I’ve explained the data and my methods.
Storage and CDN
I tested CDN77 against Amazon S3 in two different configurations, varying the source of the files and the CDN service:
- Files stored on Amazon S3 – CDN is Amazon Cloudfront
- Files stored on CDN77 – CDN is CDN77
I used two different page content configurations. Each page was a simple WordPress post using the Twenty Fifteen theme. There were no caching solutions implemented in any way, and data points were taken at least one hour from each other.
One test page had two large images. The total page size was 3.89MB and the total number of requests was 17. The other test page had 32 small images. The total page size there was 761KB, the total number of requests made was 47.
At the end of the day, this resulted in four pages, two for each CDN setup.
CDN Datacenter Locations
For Cloudfront, I used the automatic setting, which is recommended as the fastest. For CDN77 I left everything as is: all datacenters selected. The plan was to do speed tests from multiple locations, so this seemed like the best option.
Measurement Tool Used
Pingdom reported 500ms-like loading times for the almost 4MB page, which seems extremely unlikely, even with a very fast internet speed. It seems as if Pingdom cached these pages internally. Either way, I decided this was cause for alarm, so I abandoned the tool.
The page load time Chrome extension was great, but it was only limited to my own location which kind of defeats the purpose.
In the end, I grabbed a GTmetrix account and added some URL setups to monitor. I ended up with 12 monitored URLs by testing each of my four pages from three separate server locations: UK, Australia and Canada.
Once all tests were complete I compiled it all into a vast table, which draws a pretty clear conclusion: CDN77 was considerably faster!
For the large image test the page load took a whopping 54.17% longer when used with Cloudfront. The most noticeable difference was in Australia. The average load time was 4.2 seconds using CDN77 and 7.8 seconds when using Cloudfront.
The difference with a lot of small images was less noticeable, but CDN77 was still almost 2% faster on average.
The average page would fall somewhere between the two, so realistically you would get an average of 10% – 25% speed increase with CDN77, which could be lower or higher in some extreme situations.
I tested the CDN77 support service with a question I knew the answer to, a file hosting issue and a problem which genuinely had me stumped. Chat support was almost instantaneous, providing answers to all my problems.
The file hosting issue was the following: CDN77 allows you to set your origin, where your files are. When setting up Cloudfront I stored all my files on Amazon S3, so I thought it would be a good idea to try using CDN77, but keeping the files on Amazon S3 servers.
This works just fine, but to be fair I wanted to try the reverse – hosting on CDN77 and using Cloudfront as the CDN. As it turns out, this is not possible. This is not a problem by any measure, but the fact that support didn’t beat around the bush and told me this wouldn’t work within 10 seconds is revealing about the openness of the company.
The issue that stumped me was also a great support experience. I set up the local storage and it didn’t want to load the images. I know there can be delays when setting these systems up, but since my Amazon S3 experiment was up and running within 5 minutes, I thought I’d ping support after 20 minutes to make sure I set everything up correctly.
The support person confirmed that everything was set up correctly and apologized for the delay, explaining that it can sometimes take 60 minutes if there are many systems being set up at the same time. I checked my links periodically and after about 45 minutes everything was up and running.
What surprised me was that I was still logged in and the support person dropped me a line via the support chat that the service now seemed to be working, and then proceeded to apologize again for taking the max time. Now that’s attention to detail!
In addition, while writing the pricing section of this article, I wanted to confirm that CDN77’s price for hosting files was higher than Amazon’s. The chat representative immediately confirmed this, there was no beating about the bush or lame excuses. I’ve been testing some web hosting companies lately and this is less common than you might think. So kudos to CDN77 support!
Settings and Reporting
For me, a casual CDN user, CDN77 has just the right amount of options. I can set up a storage space, tie a CDN to it and set basic properties like CNAME, secure tokens and cache expiry, but that’s basically it.
With Amazon Cloudfront and S3 you can fine tune your resources any way you like. There are at least 25 settings for CDN distributions and basically unlimited for S3 if you take bucket policies, events, logging, tags and other options into account.
Bucket policies, in particular, make customized rules for your files very easy to create, although you will need to put in some time to understand how the system works.
Reporting is available in CDN77 as well. You can drill down into any of your distributions using a segmented view. Select the display type (chart, map, area, pie), the date range and the plotted data (bandwidth, traffic, hits/misses, HTTP headers, Costs).
In comparison, Amazon has more reports. You can drill down into yummy details like browser and OS access comparisons, you can create reporting alerts, view you most popular object (this is pretty handy), and more.
Pricing is a deciding factor for many people. Again, I compared CDN77 to Amazon S3 since it’s one of the best known CDN available. Basically you will incur two costs: one for storing your files with CDN77 and one for serving them.
As you can see from the table above the storage price is pretty steep compared to Amazon’s S3, although you do get 50GB free. Calculating storage with Amazon is a lot more complex, but you would pay something like $0.0295 per gigabyte, which means that storing 150GB of data would cost you about $4.50.
For many websites I think the 50GB free space will be more than enough unless you host a plethora of videos. That said, you can actually use S3 as your host and CDN77 as your CDN, which would optimize your costs.
On the CDN side, CDN77 is much cheaper. The most expensive tier (< 30TB) will cost your $0.049/GB for Europe and the US, $0.125/GB for Asia and $0.185/GB for South America. If using Cloudfront this would set you back roughly $0.80/GB for Europe and the US, $0.135 for Asia and $0.200 for South America.
On average (assuming you serve content equally to the three areas) this would set you back $0.12/GB with CDN77. Using Amazon you would pay $0.138/GB which doesn’t seem like much, but it adds up. In addition, you probably serve a lot more content to the EU and US, which would increase the gap.
To be honest, before getting to work on this tutorial I was ignorant of CDN services other than what Amazon provides. So much so, that I thought Amazon was among the quickest CDNs, which turns out isn’t true at all.
Based on all my tests I think the only part where Amazon is a clear winner is the number of advanced options you may need.