Even after SiteGround’s CDN 2.0, is it better than Cloudflare APO? My opinion is no.
It has 109 less edge locations, no HTTP/3, barely optimizes images, and you still have to use SiteGround’s DNS to use it which has proven unreliable after Google blocked it for 4 days. This resulted in large ranking drops and customer websites getting completely deindexed in Google.
Why risk it?
SiteGround just wants you to pay them instead of Cloudflare (hence, they discontinued it). It’s the same reason you saw hosts building their own control panel after cPanel increased prices.
Do you really think SiteGround’s CDN is better than Cloudflare, a CDN developed in 2009 with 3,217 employees and 192 Tbps data transfer speeds? I’ll run some tests shortly, but I doubt it.
- You have to use SiteGround’s unreliable DNS
- 176 PoPs
- Anycast routing
- Lacks image optimizations
- Lacks HTTP/3 and other features
- Unlimited/unmetered CDNs still have limits
- Test TTFB in 40 global locations
- SiteGround’s products have compatibility issues
- Conclusion: Stick to Cloudflare APO or FlyingProxy
1. You Have To Use SiteGround’s Unreliable DNS
You have to use SiteGround’s DNS to use their CDN. Here are the issues:
- SiteGround’s DNS got blocked by Google.
- SiteGround originally said “there is no blocking on our end.”
- They eventually admitted the problem, but blamed Amazon/Google.
- They eventually “implemented a fix” but never advised people to move their DNS.
- Customers lost Google rankings and some sites got deindexed from Google completely.
The question is, why wouldn’t you just use Cloudflare’s free DNS? It performs great on dnsperf.com. But hey, if you want to trust SiteGround with your Google rankings, go for it.
Status Update: We are glad to inform you that we have implemented a fix for the Google bot crawling issue experienced by some sites. Websites are already being crawled successfully. Please allow a few hours for the DNS changes to take effect. Thank you for your patience!
— SiteGround (@SiteGround) November 12, 2021
The lack of responsibility you are taking here is incredible. If this was simply Google’s fault, surely other hosts would be facing issues? Clearly something has changed on your set-up that has caused an issue. Are you aware just how damaging this is to many of your customers?
— Kim Snaith (@ichangedmyname) November 10, 2021
You should be advising people to move to an external DNS to resolve the issues if it is causing them massive losses in business. I have just sorted our connectivity issue in around 25 minutes by moving to googles DNS. If you had let us know 4 days ago, we wouldnt be £20k+ down!
— Jon Bunce (@thejonbunce) November 11, 2021
If you move to your Google Search Console > SETTINGS > CRAWL STATS you will, if unlucky like me, see something like this :-( pic.twitter.com/ocBEkWKsaw
— Tristan Haskins (@trishaskins) November 12, 2021
2. 176 PoPs
Cloudflare has 285 PoPs while SiteGround uses Google Cloud’s network with 176 PoPs.
Obviously the geographic distance from these edge locations and users plays a big role with metrics like latency and TTFB. While both have more PoPs than most CDNs, Cloudflare still wins.
3. AnyCast Routing
SiteGround’s CDN 2.0 uses Anycast which routes traffic to the closest data center and is specifically good when dealing with high traffic volume, network congestion, and protecting against DDoS attacks. It provides higher availability if a node is attacked, overloaded, or fails.
4. Lacks Image Optimizations
SiteGround Optimizer and SiteGround’s CDN do a poor job optimizing images.
One of the biggest disadvantages is they can’t resize images for mobile to improve mobile LCP. They don’t support AVIF, preloading LCP images, adding missing image dimensions to prevent layout shifts (CLS), and they can’t lazy load background images. This is why I recommend using Perfmatters on SiteGround, but resizing images for mobile is usually something your CDN does.
Cloudflare Mirage + Polish support many of these optimizations while others are usually done by your caching/optimization plugin. Bunny Optimizer also supports dynamic image resizing.
| SiteGround Optimizer | SiteGround CDN | Optimole | Cloudflare Mirage/Polish | |
|---|---|---|---|---|
| Compression | ✓ | ✓ | ✓ | ✓ |
| WebP | ✓ | x | ✓ | ✓ |
| Mobile resizing | x | x | ✓ | ✓ |
| Network-based optimizations | x | x | ✓ | ✓ |
| AVIF conversion | x | x | ✓ | ✓ |
| AVIF support | x | x | ✓ | ✓ |
| Price | Free | $7.49/mo | Free 5,000 visits/mo then $19.08/mo | $20/mo with Cloudflare Pro (or included in several Cloudflare Enterprise integrations) |
5. Lacks HTTP/3 And Other Features
Cloudflare has a plethora of settings/features not found in SiteGround’s CDN:
- HTTP/3
- Bot protection
- Rate limiting
- Page/firewall rules
- Analytics
- Signed Exchanges (SXGs)
- Better image optimization
- …among other features (especially on higher plans like Cloudflare Enterprise)
6. Unlimited/Unmetered CDNs Still Have Limits
Just like “unlimited” hosting storage, unmetered bandwidth doesn’t mean unlimited.
SiteGround doesn’t list CDN bandwidth limits, so take this with a grain of salt. RocketCDN advertises unlimited bandwidth but isn’t, since your account will be canceled at some point.
Most CDNs are either usage-based (BunnyCDN + QUIC.cloud’s CDN) or have bandwidth limits (Cloudflare Enterprise on Cloudways + FlyingProxy). SiteGround needs to be more transparent.
7. Test TTFB In 40 Global Locations
KeyCDN and SpeedVitals test TTFB in multiple global locations.
SpeedVitals recommends testing your site a few times to make sure resources are cached and served from the CDN’s closest data center. I typically use the results of the 3rd SpeedVitals test.
8. SiteGround’s Products Have Compatibility Issues
Any time SiteGround launches a new product or revamps something, do yourself a favor and wait to use it. It’s usually full of issues which they usually deny, so I wouldn’t trust their opinion.
- Their DNS was blocked by Google.
- SG Optimizer plugin has ongoing compatibility issues.
- Site Tools had a lot of bugs/missing features when first launched.
- When migrating to Google Cloud, even Backlinko reported TTFB issues.
9. Conclusion: Stick To Cloudflare APO Or FlyingProxy
Or if you’re open to a faster host, I use Rocket.net’s Cloudflare Enterprise.
| SiteGround CDN (Paid Plan) | Cloudflare + APO | FlyingProxy | Rocket.net Cloudflare Enterprise | |
|---|---|---|---|---|
| PoPs | 176 | 285 | 285 | 285 |
| Tbps | Not listed | 192 | 192 | 192 |
| Dynamic caching | ✓ | APO | APO | APO |
| Brotli | ✓ | ✓ | ✓ | ✓ |
| HTTP/3 | x | ✓ | ✓ | ✓ |
| Image optimization | Very limited | Mirage + Polish | Mirage + Polish | Mirage + Polish |
| Smart routing | Anycast | Argo (paid feature) | x | ✓ |
| Load balancing | ✓ | Paid feature | ✓ | ✓ |
| WAF | x | ✓ | ✓ | ✓ |
| DDoS protection | ✓ | ✓ | ✓ | ✓ |
| Bandwidth | Unmetered | Unlimited | 100GB | Unlimited (only hosting plan limits) |
| Price | $7.49/mo | $5/mo | $10/mo | Free with hosting |
Cheers,
Tom
I was the quote in the screenshot from Feb 2023 where I tested the siteground CDN enabled vs disabled.
I really went down the rabbit hole with this. Very frustrating.
To be fair, after that I verified with Siteground support that their CDN 2.0 was in fact NOT live yet for the site I was testing. So that was a test of their cdn 1.x. I think it went live for all users about a week later, and from what I understand, they used to have an additional DNS delay that was slowing every request down that they’ve corrected in 2.0 eliminating the extra internal DNS lookup, so that hypothetically should make the entire thing faster right there.
That said, I just tested server response time again on the same site I tested in the comment, and am getting more like 275ms now with their CDN (2.0) enabled. Also, I’m not using their Premium CDN, just the free level. So, this seems like a big improvement, but still not the lightning fast sub <100ms speeds I've seen with other CDNs.
I tested the site on Google Site Speed, and got a 100ms server response time, even better.
For the past few months, I have been using Quic.Cloud with LiteSpeed Cache plugin and getting really great performance (WHEN it's all working), but Siteground blocks a bunch of their IPs periodically causing regional downtime, and unfortunately Quic.Cloud doesn't offer any tools to check which nodes are serving 520 errors (can't reach origin server) so there's no visibility into the issue on the Quic Cloud side, the main reason I'm going to have to leave their service it seems.
I don't really want to use siteground's CDN, but since their bot-check and bot-blocking is just so intense, it seems like it blocks CDNs in general. Convenient for them that if you use their CDN, I suppose that doesn't happen. Sadly I guess I'd rather have a pretty-fast site with good uptime where that doesn't happen, than a really fast site that's just down for whole regions of the country when their system blocks an entire edge node.
Basically if any CDN needs to cache a site, especially with a pre-heat feature for example, the sheer number of hits in a short amount of time may flag the IP as a bot on Siteground's side and start redirecting to the .well-know/recaptcha bot check page, or block it outright, either way defeating the point of using the CDN in the first place and actually causing more harm than good. Or if any hacker decides to run a DDoS or a brute force attack from any of the Quic Cloud IPs, then that region's IP will then get flagged and blocked for all of their customers, which seems like a scenario with no solution.
I've had to have Siteground manually whitelist Quic Cloud IPs at least like 10 times, and that's always after it's been going on for some time. I have to manually get on Slack with Quic Cloud's support and ask them to check their node list for any given site and tell me which nodes can't reach the origin server, which also sucks on the Quic Cloud side. I use pingdom to monitor uptime but it doesn't seem to catch the issue for some reason, even though it's doing synthetic checks from lots of cities around the US, including ones where I know blocking is been happening actively.
So, as a result, I'm not sure Siteground hosting will work with any CDN at all, to be honest. And, since I'm not ready to migrate all my sites entirely just yet (probably around 100 sites between mine and my clients), and open that whole can of worms, I am looking for the best option to use with Siteground hosting and for now it seems to be their own CDN.
That sucks because their SG Optimizer plugin doesn't do nearly as good a job as compared to LiteSpeed Cache plugin or some other options out there, like NitroPack, PerfMatters, WP Rocket, etc.
If I can get a Google Page Speed score in the mid 90s or higher with their CDN 2.0 I'll stick with their ecosystem (that's what I can get with LS Cache + Quic Cloud when it's not being blocked), but if it dips back into the 80s like it used to be I'm going to probably look for a new hosting company, specifically one that has LiteSpeed servers and works OK with Quic Cloud.
That’s gotta be the most detailed review I’ve seen on my blog. Really appreciate you taking the time to write that. And yeah, definitely a rabbit hole but hopefully it can help people who are using/exploring it. Thanks Sean.