CDNS
We wrote this to clear up a bit about CDN's because they seem to be a regular selling point for many providers, and more frustratingly, plenty of people seem to want them without fully understanding the complexities involved in their deployment.
In most cases, if you think you need one of these, please consider all options. What you're benefiting from is likely caching, this is a benefit usually only because your website isn't built great, or your hosting provider isn't great. It's definitely a possibility that there is heavy congestion at your hosting provider peering links, but in our experience this is usually not the case.
Content Distribution Networks (CDN) speed up performance because of the following:
1) Your website needs caching because you are using a lower quality hosting provider that is overloaded and cannot keep up with the traffic.
2) Your website needs caching because underlying websites is not optimized, making unnecessary SQL or other network calls which are delaying the website.
3) Your website needs content closer to the request source because it's moving large data packages to destinations on distant from the source
The CDN sells #3, but for websites, you're likely to be benefiting from #1 and #2. Your CDN will likely result in more downtime, security concerns, and page delays than it benefits in page speed increases.
The quick version
CDN's aren't magic, if there is underlying performance issues in your website, the CDN may hide those but wont fix them. Eventually those performance issues will appear again. Masking your website issues with a CDN just asks for a bigger problem down the road and more costs in the interim.
If you aren't getting tens of thousands of unique visitors per day to a single website, stay away from CDN's. When you are getting those levels of traffic, your website is hitting limits, and your provider recommends a CDN, consider it, but firstly consider proxy caching and load balancing. And know full well, CDN security is tricky, and it can become easier than you'd expect to leak private data (no FUD here, just do your research and understand the CDN product fully before using it).
If you aren't getting those levels of traffic, and your website is slow, and you've seen a CDN improve performance in a very measurable way - Test different hosting providers and analyze your website for inefficiencies.
The longer version
We're going to create a scenario that is easy to understand but also not too scientific (so don't be a lawyer about it :). If we fudge a few numbers here it's not because we are being disingenuous, but instead trying to make something reasonably complicated a bit easier to understand.
Example : Starting Point
In this example, let us pretend that you have a widget you are selling from your website. Your business is in Chicago and although your primary target audience is in Chicago, you still sell throughout the United States, the the website itself is hosted on a bulk hosting provider in California.
We'll start with a timer of 0 seconds here.
Step 1 : latency due to distance
Let us assume that data can travel from those two locations in maybe 100 ms after we account for all reasonable switch paths and your home router being a bit delayed by your kids playing video games. That's 1/10th of a second.
+0.10 seconds
Step 2 : delay due to web server
Let us also assume that your data cost to acquire is 200ms. This is the process of your web browser communicating with the remote server and getting the data packaged to send, performing TLS encryption, and pulling content off the disks. An additional 1/3rd of a second.
+0.30 Seconds
Step 3: delay due to content size
Let us assume you data package size (the full website page, images and all) is 8MB, and will take a typical broadband connection around 4MB/second to download. (We normalized data values here to "megabytes" to make it easier to understand). 2 seconds in total additional time.
+2.0 seconds
Step 4: delay due to end-user performance (or poor website design)
Lastly, your browser has to compute what it's received, organize it on the screen, and make all the pretty pictures appear. A reasonably recent computer, given decent code maybe takes an additional 200ms.
+0.2 seconds
Final Time to Deliver: 2.6 Seconds
0.10 + 0.30 + 2.0 + 0.2
2.6 seconds seems fast, so why do we need a CDN?
Yeah, exactly. But lets take a look at what is really happening with your content from are more realistic perspective.
Step 1 above - We spoke of distance latency, this isn't something we can fix, largely due to speed of light. So ignoring routing delays or issues that should mostly be sporadic. Lets leave this number alone.
Step 2 above - A web server packing up the data and sending it down the pipe at 200ms? This number is wildly inaccurate for bulk or overloaded hosting or poor website designs that hit database servers with large page requests. In many cases the number isn't 200ms. We've seen overloaded hosting companies, and poor website designs run this number up to 4-5 seconds easy during busy hours. And many 'typical' hosting companies will return data in 1 second or more.
+1s (off hours) to 4s (peak)
so lets just average to 2.5 seconds.
Step 3 above - A a delay due to content size costs, which we limited at 8MB. We've seen plenty of 'website developers' upload 12MB images for their webpage and then wonder why their website is loading slowly. Additionally, even sizes at 8MB can be slower if we include cafe wifi or overloaded cell towers reducing our broadband speeds down to 1-2MB/second.
+3 second for badly designed websites, probably more if we include cellular reception performance, etc.
Step 4 above - A delay due to end-user performance, which we measured this at 200ms. We'd love that to be typical, but specifically with CMS solutions including lots of plugins, this number can quickly skyrocket into the seconds. Countless times have social media plugins that request real time data from 3rd parties gotten in the way of content delivery. Much of this can only be fixed by better website design though, so for now we'll just leave this at 200ms.
New Math: 0.1s + 2.5s + 3s + 0.2s
Final time to deliver: 5.8 seconds.
So we have a perfect world solution, quality hosting, reasonably built website with large content size above the fold, delivering in 2.6 seconds. And then a overloaded hosting or bloated websites delivering in 5.8 seconds (probably slower if you happen to be hosting both a bloated website on poor hosting infrastructure). And the argument that CDN's have is that you need them for caching data closer to the source of the request?
No. You need them to just cache the data. Putting your content closer to the source isn't saving you but the first 100ms of the above equation.
If I can bring 100ms down to 50ms by bringing data closer to your location, that's a tremendous improvement in performance, but it's still 1/20th of a second. When you are waiting for a page to load, 1/20th of a second isn't your problem. It's the next 5 seconds you are wondering what is going on as you're staring at a blank screen.
If I can bring my 8MB data package closer to your location physically, that also can speed up a few areas as during some peak hours the bandwidth may be too contentious, and your performance may be delayed a bit nationally (again delivering to Chicago from California). Again, maybe another 1/10th of a second during peak load times of the day, but 1/10th of a second isn't your problem, it's still the next 5 seconds we are curious about.
As you can see, these aren't exactly massive savings in what the CDN advertises by bringing data closer to your location.
OK, but I installed a CDN and the site is faster, why does a CDN really help?
Caching.
Some TLS offloading (mostly historical), but mostly caching...
We have first-hand witnessed overloaded MySQL and PHP servers with rather small WordPress sites taking 8 seconds to deliver what should take 1/4 of a second. A server in which the client had a 1 second load time just 6 months earlier. If you front-end cache a large amount of this data in memory on servers that don't need to perform database lookups, all the heavy processing, typically for *SQL lookups, are avoided.
CDN's bypass the web server delays (#2 above) by delivering from their content servers instead of using the overloaded source server. And although this is nice initially, the flaws become apparent quickly with this additional layer of caching and indirection causes unexpected hiccups: stale cache, missed logging analytics & statistics, security concerns (most CDN's are caching data in shared repositories for thousands of unrelated websites), and client privacy tracking are just a few of the immediate issues.
The CDN does provide a much more consistent response performance if you can guarantee CDN performance across the board, but in practice that isn't our experience. CDN's are technical, and have issues as well, sometimes even the CDN itself is running hot and causes a speed reduction. Other times the CDN has improperly cached data, causing outage or even showing products 'still in stock' which are actually sold out (or worse, leak private information). The potential for issue is vast, and many times they will go unnoticed because the caching servers close to your location are showing proper content.
Ok, I get it, but my site is slow, and I want it faster?
1) Build a better website. That wasn't intended to be rude, please dig deeper into your website firstly, make sure there isn't large amounts of SQL calls, watch error logs and slow logs for performance issues. Disable as many 3rd party resources and javascript resources being called which bloat the website and cause the client to make many round trips to 3rd party locations.
2) Use quality hosting. Stay far away from any bulk hosting companies that have multi-year lock-in's, most of these end up being reasonable initially, but by month 6 they start to slow down and aren't worth the hassle. Typically, any company that can get you in the door with multi-year contracts either knows their product is low quality, or you are too big of a client for them and they need contracts to offset the infrastructure investment they are making. The latter case isn't terrible and should be something each company spends time considering. The former case seems to be a common predatory event in website hosting.
3) If you have the resources to bring this in house, do your best to keep your data on high speed hardware managed by competent administrators and website designers.
4) If you happen to be servicing tens of thousands of visitors, or your website is still slow and are left without choice, look into front-end caching with products like nginx or varnish cache, and be prepared for some additional cache management requirements and the complexity that comes with it.
Any arguments for CDNs?
We've talked with some clients that have used them not for the CDN properties, but instead for the security properties some bundle in to protect legacy products that are under development. This is a fair recommendation.
We've also seen these deployed in the real world for moving large packages (movies, video games, operating systems) closer to the request destination. Again, a fair recommendation.
Additionally, we'd consider this option if you are an international business and you can see the step 1 above delays causing a noticeable problem. Though, we'd argue that in these cases you're probably better off just implementing in-country servers dedicated to that market...so maybe this one isn't a great argument for CDNs.