Who Is Hosting This

To the visitor, all content delivery networks operate the same way. Edge locations across the globe provide critical content to them at a great accelerated pace due to their proximity. However, to the webmaster, they often work in radically different ways.

The biggest difference to weigh is whether or not the CDN is a “Push” CDN or an “Original Pull” (or simply “Pull” ) CDN. The two systems work in radically different ways and each have their own advantages/disadvantages to consider.

More importantly though, one CDN type may not be an option for a particular site or may not be a good choice. As such, understanding the differences between the two is crucial when trying to decide which service to go with and how to best use it on your site.

With that in mind, here’s a quick breakdown of the two types, what they are best at what cases they are correct for.

Push CDNs

Generally speaking, a push CDN works very much like second server. The user, either by hand or through some kind of automated process, uploads content directly to the CDN for hosting and links to it. Some push CDNs support FTP while others, like Amazon Cloudfront, support REST and SOAP and other protocols.

The idea is that the user, or their main server, takes responsibility for providing content to the CDN, “pushing” it to the network. This allows a great deal of flexibility with how the CDN is used. Users can specify what content is uploaded, when it expires and when the content is updated. This method is also the most efficient in terms of how the traffic is used, content is uploaded only when it is new and when it is actually changed, thus keeping the amount of traffic in and out of your server to a minimum.

Origin Pull CDNs

An origin pull CDN works very differently from a push one. With a pull CDN, the site owner simply leaves the content on their server and and rewrites their URLs to point to the CDN. When asked for a specific file, the CDN will first go to the the original server, “pull” the file off of it and serve it. The CDN will then cache that particular file and not query it again from the original server until it expires.

This means that, instead of the user taking responsibility for putting files onto the CDN, the CDN does it for them. This has the benefit of being very easy to set up, often just a simple matter of rewriting URLs to include a subdomain, and it minimizes the number of files stored on the CDN at any one time. However, it does reduce the flexibility of the CDN, creating a one-size-fits-all approach to the files on the service, and can create redundant traffic as files are re-queried before they have been changed.

This method of content delivery is also slower for people who are first trying to access the file or access it immediately after it has expired. The reason is that the CDN has to query the original server, pull the file and then serve that, creating a delay. However, usually one can set the expiration to keep this, as well as delivery of old content, to a minimum. Purge tools and APIs, however, can also help ensure that the delivered content is fresh if necessary.

Choosing the Correct CDN

For most sites, the process of setting up a CDN is fairly automated, especially if using a program such as W3 Total Cache, this makes the one-time setup of a CDN fairly painless and eliminates much of the difference in that regard. However, not all sites have this capability and, in those cases, the headache of setting up a CDN may well be a major selling point.

More to the point though, the two different CDN types each favor different kinds of sites. For example, sites that receive a great deal of traffic, where content remains relatively stable and the traffic is spread out fairly evenly across the files on the CDN, typically favor pull CDNs. These types of sites reduce the number of unneeded content pulls by allowing the webmaster to set the expiration high and also ensures that the vast majority of visitors get served content cached on the CDN, rather than being pulled fresh.

On the other hand, sites with minimal amounts of traffic, especially those that receive only a minimal amount of visitors to the majority of its items, will fare better with the push system as the content is put onto the CDN once and left up, rather than re-pulled at regular intervals.

For example, a podcast where most of the episodes are older and rarely accessed (but also never updated) is likely best served over a push CDN as is a medium-traffic blog where most of the images are rarely accessed. However, a high-traffic image site where the visits are more spread out such as an image hosting service, may be better served over a pull network, especially as they are often changed out.

However, either system can easily work for any kind of site, it is just a matter of finding the correct automation techniques and setting the expirations correctly.

Bottom Line

In the end, each system has their own advantages and disadvantages, however, with proper configuration, they can be easily mitigated W3 Total Cache, makes it easy to use either system, including most pull systems, and enables experimentation.

More important than the system the CDN uses is how well the CDN performs and, more important than that, is the fact you are using one. In short, rather than worrying too much about which CDN system is best for your site, it is more important to find one that works for you and to implement it well. If you do that, you’ll almost certainly see a major performance increase and that will translate to more visitors, happier users and higher search engine rankings.

However, since the type of CDN can have a major impact on how you implement the system and that, in turn, makes it important to be aware of the differences so you can get the most out of whichever system you choose to use.