To CDN or not to CDN

I debated whether or not to use a CDN for Maison Miru Guides for a long time. After all, most of our traffic comes from the US, our SiteGround plan offers unlimited traffic, our blog (at this moment) is pretty minimalist, and a CDN adds another level of complexity to the software stack. In the end, I got tired of getting penalized by YSlow in GTMetrix and decided to take the plunge.

For most sites on SiteGround, Cloudflare is the easy and obvious choice – it can be turned on with one click, there’s no cost for their basic services, and you get access to performance enhancements normally exclusive to paid plans, like RailGun. I wasn’t able to use any of this.

The SiteGround/Cloudflare integration requires that your website live on the WWW subdomain, but Maison Miru Guides does not. We toyed around with registering a new domain for the project instead, but wanted to enjoy the branding benefits of being on the same domain as our primary business. I could have also signed up with Cloudflare directly, but that would have required moving the entire domain to Cloudflare’s DNS. While this might actually be a desirable thing to do long-term, I was not about to make that decision as part of this test.

Instead, I decided to try and integrate with an existing KeyCDN account that we happen to have for our Klaviyo click-tracking. KeyCDN is a popular choice because they have low bandwidth costs and a simple WordPress plugin that rewrites all your static resources to load from their servers. This is where the fun began.

KeyCDN actually has a fair amount of documentation on various ways to integrate with WordPress, including some simple setup instructions for CDN Enabler. I found these instructions somewhat lacking. For starters, I wanted a zone alias for my CDN, so I needed to use the slightly more advanced instructions here. Next, I found that my KeyCDN pull zone defaults were still causing GTMetrix to complain – I’m not sure if this is true for everyone or a quirk of my account, but my pull zone was set to override whatever cache settings were sent from the origin server and use 7 days instead. Here’s what my pull zone looks like now, which is pretty similar to this article I found about full-site caching (I’m not sold on doing full-site caching yet, as you need to mess with Apache/nginx config, but KeyCDN also has a nice guide which talks about a few of these settings):

  • Ignore Cache Control: disabled
  • Ignore Query String: disabled
  • Forward Host Header: disabled
  • Cache Key Scheme: disabled
  • Cache Key Host: disabled
  • Cache Key Cookie: disabled
  • Cache Key Device: disabled
  • Cache Key WebP: disabled
  • Cache Brotli: disabled
  • Cache Cookies: disabled
  • Strip Cookies: disabled
  • X-Pull Key: KeyCDN
  • Canonical Header: enabled
  • Robots.txt: disabled
  • Optimize for HLS: disabled
  • Generic Error Pages: enabled
  • Image Processing: disabled
  • Force Download: disabled
  • CORS: enabled
  • Gzip: enabled
  • Expire (minutes): 0
  • Block Bad Bots: disabled
  • Allow Empty Referrer: enabled
  • Block Referrer: disabled
  • Secure Token: disabled
  • SSL: letsencrypt
  • Force SSL: disabled

Next, I encountered the issue here, namely that rewriting all your static assets can sometimes prevent Google from indexing your images. To this day, I’m not actually sure I was affected by this behavior, but I’ve made the changes described there just in case.

Next, I ran into an issue where my SG Optimizer combined JS/CSS files were empty. This was happening because of a bug/feature in CDN Enabler where it was rewriting all my assets to the CDN before SG Optimizer processed them, so SG Optimizer thought there was nothing to optimize. There’s a pull request to fix this, which I’ve manually applied for now.

Finally, when creating staging sites, I always need to disable the CDN because it will pull assets from my main site, and they may not yet exist if I’m making post/JS/CSS edits on the staging server.

After all the time I spent on this, I think a Cloudflare setup is just easier – you really don’t need to think about any of this for full-site caching, whereas I needed to comb through settings, documentation, and even plugin code just to get static asset caching working at it’s best. Even the cheap hosting service I use for this blog let me set this up rather trivially and it feels blazingly fast + has none of the SEO and staging concerns I ran into with a partial setup.

Leave a Comment

Your email address will not be published. Required fields are marked *