Road to scalability is paved with good intentions and semi-correct information. One such advice is to use a CDN if your site is slow or has a global audience.
In theory, it makes sense. CDNs have POPs all over the world, and all of them cache heavy assets from your site, then deliver them from a location closest to your visitors.
But what actually happens when a visitor visits your site?
Browsers and the networking layers do their thing, translate the domain to IP, open a TCP connection, do the TLS handshake, and so on…
After this, the server needs to send the HTML skeleton to the browser before any static assets are downloaded (Unless you use HTTP2 Push, but that’s a different topic).
The time it takes between the user requesting a URL and server sending the HTML skeleton is called time to first byte, or TTFB. While CDNs may speed up the delivery of images, CSS, and JS assets, more often than not, they don’t help you reduce TTFB.
What does this mean for WordPress then?
Well, unless you configure the CDN also to do HTML caching, your site’s load speed still depends on server’s response time. This is why CDNs don’t magically solve performance issues. If you configure CDN also to cache HTML, it breaks WooCommerce and any dynamic functionality.
There is another issue with the theory that CDNs speed up the delivery of images and large assets.
CDNs like Akamai and Fastly have the option to cache all static assets at all POPs all the time. On the other hand, Cloudflare and Cloudfront cache assets at a POP _after_ they are requested for the first time.
Here’s an example.
Even though Cloudflare has a POP location in Rome, Italy, the first visitor from Rome needs to download all assets from your server in Virginia. Cloudflare then caches these assets for the next visitor in Italy.
Roughly translated, a CDN in this scenario does nothing to speed up your site but adds a few more milliseconds and an additional network hop. Now, if you have a steady stream of visitors from Italy and Virginia, a CDN might be a good idea.
A better approach to this type of global website is creating localized or country-specific versions and hosting them near to the visitors. This way, visitors from Italy can get the HTML skeleton from a server in the EU, and visitors from the US can get their assets from a data center near to them.
The best part of this setup is that this performance boost doesn’t rely on the CDN cache to shave off a few milliseconds of page speed. You also benefit from a lower TTFB, which helps with conversions and audience engagement.