Beyond Speed: 5 (More) Reasons Why You Should be Using a CDN
You’ve probably already heard about CDNs, you know, they help make your website faster. Yet, you might feel that after paying for web hosting, why should you pay the same amount (or more!) for a CDN? Shouldn’t your hosting already do all of this stuff?
There’s a significant difference between the infrastructure required for hosting sites and the infrastructure required for hosting a CDN, that’s why these are two completely separate services.
But why do you need a CDN? Is it speed and performance? Or is there more to it?
Today, we’ll take a look at a few additional benefits of having a CDN, which you might not know about.
1. Speed – How a CDN Makes Your WordPress Site Faster
One of the major factors that can make your site slow is the distance your content has to travel between the server hosting your website and the location of the visitor of your site. Simply put, the further the location, the longer your site will take to load.
A CDN’s primary purpose is to reduce the physical distance that your (heavier) content has to travel.
This is how it happens:
In the diagram below, we can see in detail the concept of how a CDN works.
For example, below you can see the global server network of a CDN service, in this case CloudFlare.
If your site is hosted in the US, and your visitor is in Europe, the heavier images will be served out of the Europe data centers.
Vice-versa, if your server is based in Europe, and your traffic is coming from the US, one of the data centers in the US will be used to serve the heavier content.
Now, besides physical location, the size of resources is another determining factor in speed. What if you could optimize your site such that it has the best of both worlds?
I’ll discuss this further in the final section of this article.
2. Performance – A CDN-Powered Site is Able to Handle Much More Traffic
While speed and performance go very much hand-in-hand, they are quite different. Getting your site to load faster when there are no visitors is one thing. Getting your site to still load fast when your site is under heavy load is a totally different ball-game. Getting your site to load fast under no load is simply a matter of optimizing for faster loading times.
But for your site to load fast under heavy load, your site needs to scale out – the load needs to be handled by multiple servers. And this is another way how a CDN can help your site.
To understand this, we need to actually understand how a CDN functions. There are two ways you can implement a CDN.
Deployment Scenario 1: Redirect Static Resources to the CDN Server
In this first method, your site uses a CDN by rewriting the address of the static resources, such that rather than loading from your own hosting server, they load from the CDN server.
For example, let’s say we’re powering our site using a CDN redirect plugin. An address such as:
is now rewritten as
You’ll need to perform some changes in your DNS structure, such that the address cdn.example.com will point to the right hostname of the CDN service you will be using.
Given that all of your static resources will now be pointing to the URL of the CDN, they will all be served via the CDN rather than through your own server.
The drawback of using this approach is that ALL traffic hits will be direct to your server. However, there is another way that can significantly reduce the load on your server.
Deployment Scenario 2: Use a CDN as a Reverse Proxy
The diagram below depicts how a reverse proxy works.
Activating a CDN using a reverse proxy also requires minor changes to the DNS, such that your domain now points to the CDN rather than to your site.
This means that all traffic is first sent to the CDN servers rather than to your site. The CDN then makes a request to your server for any dynamic content required by the visitor and then serves all of the static and dynamic content to your visitor.
What this means is that the bulk of the load is handled by the CDN servers.
The fact that the load of traffic is being shared by your own server together with the CDN server network, means that your site will be able to handle much more load than it would be able to if it didn’t have a CDN in place. (By the way, if you’re looking for a good hosting server which has great protection, we can’t complain about the hosting of my personal website).
Couple that with a page caching mechanism, and your site is now both fast and can handle heavy loads.
3. Security – A CDN Has Built-In Security to Stop Malicious Traffic
As a security freak, I’m happy to recommend and implement any mechanism that makes my sites more secure.
Frankly speaking, fixing a hacked WordPress site is not pleasant. Security plugins such as Defender are one of the very first things I install on any site, yet I’ll gladly take any leg-up I can get in terms of security.
CDNs have plenty of built-in mechanisms to deal with malicious traffic.
If you had to take a look at the direct access traffic logs of your server, you’ll probably notice that a very large portion of traffic to your site comes from (ro)bots. You’ll see this marked as not viewed traffic.
Bots are automated visitors to your site that perform a specific function.
Incapsula, in its 2016 bot report, estimated that 51.8% of traffic is actually bot traffic rather than humans! Some bots such as the Google crawler bot, and the Facebook bot, visit your site to extract information and make sure your site is as visible as it can get. These are the good or benign bots. These bots made up about 23% of all website traffic in 2016.
1.6 million WordPress Superheroes read and trust our blog. Join them and get daily posts delivered to your inbox - free!
Then there are the malicious bots, and boy there’s a lot of them.
In 2016, about 29% of website traffic came from bad bots. We’re not going to delve much into what bad bots are, but suffice to say, they’re not doing your website any good. The typical bad bots are either impersonators, sites which mimic legitimate tools to try and attack your website, or straight up malicious hacking tools.
Most CDNs have built-in mechanisms to implicitly block bad bots, which will not only reduce the load on your server but also prevent many of attacks from happening in the first place.
Web-Application Firewall (WAF)
CDNs typically have an enterprise grade firewall in place to stop various kinds of attacks on your site. Besides protecting against the most critical web application security risks, such as SQL injection, cross-site scripting, illegal resource access, remote file inclusion and other top threats, a WAF can be used to define custom rules to apply to your site.
These rules can target anything, from the origination of the geographical location of the request to your site, to very detailed rules, such that you are as granular as you need in the protection of your website, particularly if you’re being persistently hit by a spate of particular attacks.
There are various types of hackers, but the ones we find to be particularly nasty are the ones who stay under the radar. When your site is clearly and obviously hacked, there are ways to discover and fix it. But, if the hacker simply installs a backdoor, you are at their mercy.
This is because, with a backdoor installed on your site, the hacker can remotely control your website at will. Using their Command and Control centers, they will be able to perform actions (malicious, destructive or spammy in nature) which makes your website a party to these malicious activities.
A good CDN will be able to protect from backdoors being installed. It can also actually discover any existing backdoors on your site and neutralize them.
We still haven’t spoken about another scourge of today’s web: DDoS attacks.
4. Prevent Your Site From Going Down During a DDoS Attack
Further up in this article, I discussed how implementing a CDN as a reverse proxy can help your website handle traffic spikes and improve its performance. But nowhere will this performance be more evident than if your site is under a DDoS attack.
A DDoS, or Distributed Denial of Service, is a malicious attack that kills your site completely for as long as the site is under attack
In a DDoS attack, an army of computers or servers that have been compromised is recruited to send a flood of traffic to a particular website, such that there is so much “fake” traffic that the site is overwhelmed. At this point, legitimate traffic can no longer get to the website.
There are various reasons why a site can suffer a DDoS attack:
- Hackers are attacking your site such that they can blackmail you into paying them a fee to stop the attack
- You get caught in the cross-fire of a DDoS attack on a website hosted on the same shared server as you – your website is the collateral damage
- A competitor wants to damage your brand/reputation/income
There are plenty of other reasons why DDoS attacks are performed, but these would be most common.
Whatever the reason for the attack, once a DDoS attack is set in motion, your site is dead in the water. The amount of data flooding your site can NOT be handled, no matter the size of your hosting account.
The “Distributed” nature of a DDoS attack makes it practically impossible to mitigate using traditional techniques such as blocking IPs, range of IPs or geographies. The attack comes from so many diverse sources that it’s not possible to block it using traditional blocking mechanisms (firewalls, deny rules, etc.).
So how can you mitigate a DDoS attack? That’s another way a CDN can help your site.
As we discussed above, a CDN has servers all across the globe. By implementing a CDN using a reverse proxy, your site is not served by a single server, but by multiple servers across the globe.
Moreover, CDNs are able to “recognize” when a DDoS attack is in place and can discard the malicious traffic as it hit the CDN servers, ensuring your actual server is not hit by the load of malicious traffic coming from a DDoS attack.
Once your site has been targeted for a DDoS, only a service aimed at mitigating these attacks can help your site.
My opinion? I’d rather be safe and activate a CDN before my site(s) get hit.
5. Taking a CDN’s Performance One Step Further
Back in the first section, we discussed speed and how CDNs can help your site.
At WPMU DEV we know that there is another major factor which can slow down your site: the actual physical size of your images.
Many of the images we use on our sites are typically optimized to look awesome, which comes at the “cost” of the size of the image.
Images that look great are typically larger in size, and that size comes at another cost – the loading time of your site – the larger the size of the images, the longer your site takes to load.
Again, simply put, to make your site load faster, your images need to be optimized for the web, removing any superfluous weight, such that they are as lean as they can get (without losing quality).
Most of us know this already, but if you are like me, you probably don’t have time to go through the process required to optimize each and every image on your site. Even if you do have the time, I’m simply too lazy or just plain forget to do that.
And that’s where WPMU DEV comes to the rescue with Smush Pro.
Smush Pro is an image compression plugin that springs into action each time you upload a heavy piece of content on your site. If you upload an image that you didn’t optimize, the plugin “smushes” that image into submission, compressing the image to a size that is great for the web without losing any of the quality.
The new version of Smush Pro goes much further than, though – it’s built to super-optimize ANY image in any directory, not just the images in your media gallery.
Ready to Make Your Site Fast and Secure?
There are plenty of other benefits having a CDN can offer your site. HTTPS certificates, minification and compression of content, purging of content caches at will but really and truly we do believe the above are critical to the success of your site.
I’m strong of the opinion that a CDN is essential to your site. Do have a look at our preferred list of CDNs for WordPress, and when your site is faster, leave a comment below and share your experience.