Why WordPress Sites Should Use a Content Delivery Network
Last Updated -
I recently started working with one of the top Obstacle Course Race media sites, a WordPress site. My role is help with the technical side of the site, which includes making sure it is up and running at all times from everywhere.
This is a project I inherited from a friend, who did a pretty decent job making the site as technically sound as a WordPress site can be, but there are some improvements that need to be made.
I realized late one Friday night the site is not properly using a Content Delivery Network. Unfortunately, I have been examining WordPress sites more often in the past year I have been spotting many patterns of improper technical setup. Bad use of CDNs is just one common mistake I see scaled by many WordPress sites.
So, what is wrong with ORM's use of a Content Delivery Network (CDN)?
There is no CDN being used, that's the problem!
The web pages are not served via the CDN, only the supporting assets. This means when the web server is inaccessible the site is down. That is what prompted me to investigate a problem with the ORM site late that night.
Note I said 'the web server is inaccessible', not down.
The site's web server was up and running, but there is something broken between my home connection and the hosting company's server. The assets are the CDN are available since they are served from somewhere else, a CDN.
ORM is not the only site suffering from mismanaged use of CDNs, this is a problem systemic to much of the web, particularly CMS based sites, like WordPress.
I see it all the time.
Mixed Website and CDN
Andrew Welch recently wrote about how the background-image CSS property is an anti-property. One reason he used to justify his position was how it potentially messed up the use of a Content Delivery Network.
His case definition is a website that wants to host its images on a CDN so it can handle scaled demand, around the world. He argues it creates a point of friction having to do a global search and replace to point the image url reference to the now CDN hosted image.
Of course, the problem with Andrew's scenario is the website was not configured properly in the first place, with the CDN being the primary web server.
It is deep into 2019 right now and the cost of using a content delivery network is negligible. Setting up and managing a CDN service is also pretty easy, especially compared to where we were a decade ago.
So basically there is no excuse not to use a content delivery network as your front-line web server. In fact, I argue you should not even use a traditional web server in today's world of serverless cloud computing.
Let look at how to use a CDN, why WordPress and most CMS platforms are broken and why you should take away to improve your website today.
The Problem with Improper CDN Usage
The common configuration when a website uses a content management system, like Magento, WordPress, Shopify, etc. is the web content is served directly and maybe the supporting resources (CSS, images, scripts etc.) are hosted on a CDN.
This really defeats the purpose of using a CDN to distribute your site. You have created a single point of failure and a choke point.
If your website goes offline or is potentially blacklisted by an Internet provider the CDN hosted assets won’t be requested because the HTML is not accessible.
With a CDN your content is distributed to different locations there are effectively multiple points of failure. If one server goes offline or is potentially blocked by a blacklist there are additional servers that can pick up the slack.
Unlike a single shared web server where an IP address can find its way to a blacklist content delivery networks are a little less susceptible to this issue.
There is another problem hosting site assets on a separate domain create, at least one additional HTTP connection. HTTP connections are expensive and should be limited as much as possible.
HTTP/2 eliminates many extra connections because it multiplexes requests using a single connection.
Speaking of HTTP/2, most traditional servers still do not have HTTP/2 enabled or lets just say most classically hosted websites don't seem to be using HTTP/2.
HTTP/2 is typically a standard feature offered by CDN services. If HTTP/2 is not available, it is grounds for immediate rejection.
Whether you use dedicated servers or shared hosting, it is expensive to scale the platform the meet demand.
Granted most sites never see enough traffic to really worry about scaling, but if you need to meet high demand a CDN is your friend. They are designed to scale.
How to Use a Content Delivery Network
Cloud computing has made CDNs accessible. Not only have they made them easy to setup they have also turned the service into a cheap commodity that can almost completely replace your traditional hosting costs.
There are numerous services available to site owners. I utilize Amazon's AWS CloudFront for my properties. I host, store really, my website content in S3 buckets and CloudFront integrates easily with its sibling AWS service.
Azure offers a similar service however its static site hosting is still a little fragile in comparison.
KeyCDN, Cloudinary, Fastly and dozens of other services offer content delivery networks as well. Pricing for most of these services is almost identical.
Key differences tend to be how many local instances are available and some are slightly faster than others.
When you employ a CDN you configure the service to point to one or more content origins. This is typically the web server.
Once you do that the server is only accessed by the CDN. This reduces the demand on the server since static content is cached in the CDN nodes around the world.
I won’t get into strategies for dynamic content here, but you can still offload dynamic content demand. The actual implementation varies by CDN service, the origin web server and the application personality.
Key Takeaways
The problem I encountered with ORM's site was probably due to the web server's IP address being on a blacklist. Most likely one of the sites on the server was doing some bad stuff, which caused it's IP address to get picked up by a blacklist Verizon is using.
ORM is not alone. I see this a few times a month when trying to visit some sites. CMS based sites tend to have this problem more often than custom built sites since they tend to be less professionally configured.
If you are using a CDN, but you are not pointing your domain to the CDN to serve all your site then you need to address this issue sooner rather than later.
Cost should not be a blocking factor as the services have become commodity services.