Some online experts say that a CDN or content delivery network will make a site load faster because of the way it retrieves data.
The actual answer is sometimes yes and sometimes no. It depends on the hosting environment, quality of the CDN, the amount of traffic a site receives, how well the site is already optimized for speed, and other important factors.
What is CDN?
A CDN is a series of servers in data centers around the world. Visitors to a website that use a CDN will download static cached content from the nearest available data center rather than the original server hosting the site. The closeness of the data center to the location of the visitor speeds delivery of that content.
Imagine a website on a server in Chicago that doesn’t use a content delivery network. A visitor from Beijing retrieves a page from that site.
The data representing the text, graphics and scripts from the page must travel over a series of networks and routers that make up the Internet between Chicago and Beijing half a world apart.
A ping test tool shows the response time for a website from various servers around the world. Results often prove the closest server gets the fastest response — sometimes 10 times faster than the farthest server.
So a cached copy of that Chicago website stored at a data center in Paris will likely respond more quickly to the Beijing visitor than the original one in Chicago.
For that reason alone, it makes sense to consider using a content delivery network. But it’s not that simple.
CDN Hosting Limits
Multiple tests on two identical pages — one using a CDN and the other not using it — produced the same startling results.
The page that didn’t use the CDN downloaded twice as fast as the page that did use one. The test defied the above example.
The waterfall, which shows the download times for each object on the page, revealed that the CSS stylesheet and especially the images hosted on the CDN took much longer to download than they did without the CDN.
The images took anywhere from about 500 milliseconds to two full seconds versus an average of about 100 milliseconds for the site without the CDN. All of the wait was split between connecting to the CDN at Amazon and then waiting for a response.
A posting on StackExchange had this possible explanation:
CloudFront’s closest edge servers are farther away from your particular location than your web host.
The additional DNS lookup is increasing TTFB (time to first byte). If you’re using a custom origin server instead of S3, this could cause further delays on cache misses as the edge server has to do a DNS lookup of your origin server.
Cache misses: if your file isn’t found on the edge node, then it has to be pulled from the origin server. The longer your TTL (time to live) and the more popular your site is, the less this effect will be felt by your users.
The Edge node used is currently experiencing high loads.
The explanation sounds reasonable. But in the case of this experiment, the closest edge servers were just as close as the hosting company servers.
The time to first byte was nearly the same for both pages. The cache did not appear to miss because the test ran over multiple times with the same result. The edge node did not seem to have high loads for the same reason.
Although highly technical specialists may find other reasons, the test may lead someone to conclude that a combination of a domain lookup and consistent load on the CDN led to slower results.
Lessons On Choosing a CDN
This somewhat limited series of tests lead to a few important lessons about whether a content delivery network is worth the labor and extra cost.
- Do everything possible to optimize a site for speed before spending time and money on a CDN.
- Test the CDN before making a commitment. Amazon, Google and others are so inexpensive for testing that the risk is low.
- CDN quality matters. A CDN more expensive than Amazon may produce better results.
- It may be worth the money for a large, high-value site. It may not be worth it for a small one that doesn’t generate enough revenue to justify the cost.