QUIC.cloud CDN Review With Setup Instructions: Excellent CDN For LiteSpeed (But Ideally Use The Paid “Standard” Plan)

Quic. Cloud cdn review

Is QUIC.cloud a better CDN than Cloudflare or BunnyCDN? How do you setup QUIC using LiteSpeed Cache? Which method should you use to set it up, and should you use QUIC’s DNS?

To answer the first question, the paid version of QUIC.cloud (called the standard plan) is much better than the free plan which only uses 6 PoPs in the US + Europe and lacks DDoS protection. The standard plan is more comparable to paid CDNs like BunnyCDN and uses all 83 PoPs with regional pricing (very similar to the pricing of BunnyCDN). In other words, for a free CDN, you’re better off using Cloudflare’s 250 data centers compared to the 6 PoPs on QUIC.cloud’s free plan.

However, a key benefit of QUIC.cloud is it caches HTML (dynamic content) which is  similar to Cloudflare’s APO. This can improve TTFB in multiple global locations when testing your site in KeyCDN’s performance test. By default, QUIC.cloud is only setup to cache dynamic assets (caching static assets can be enabled in the CDN config settings of your QUIC.cloud dashboard).

Which means you could use QUIC.cloud to cache dynamic assets, then another CDN like Cloudflare or BunnyCDN to cache static assets. Since Cloudflare and BunnyCDN are listed on cdnperf.com, it’s easy to judge their performance/reliability. But since QUIC.cloud isn’t, it’s hard to know how it compares to other CDNs. Assuming you’re open to using the standard plan (not the free plan with only 6 PoPs), it’s definitely a CDN I would try setting up and testing the results.

  1. QUIC.cloud vs. Cloudflare vs. Other CDNs
  2. HTML Caching
  3. Free vs. Standard Plan
  4. Setup Instructions With LiteSpeed Cache
  5. Image, Page Optimizations, And LQIP
  6. CDN Config Settings
  7. Final Thoughts


1. QUIC.cloud vs. Cloudflare vs. Other CDNs

Key differences between QUIC, Cloudflare, and BunnyCDN:

  • PoPs – QUIC has 6-83 PoPs depending on whether you use their free vs. standard plan. This is lower compared to BunnyCDN’s 90 PoPs and Cloudflare’s 250. Keep in mind that QUIC is newer and as they grow, they will likely expand their PoPs with more locations.
  • DNS – Cloudflare’s DNS is generally faster than QUIC.cloud’s DNS which uses AWS’s Route53 (see dnsperf.com). You can still use Cloudflare or an external DNS with QUIC.
  • HTML caching – QUIC.cloud caches both static and dynamic content (HTML) while you would need something like Cloudflare APO or Super Page Cache for Cloudflare to do this. This can make a big difference especially when testing your TTFB in multiple locations.
  • Features – all CDNs have a unique set of features that range from DNS to security and speed optimizations. However with many CDNs like Cloudflare, your traffic has to be proxied through their CDN for many features to work (and won’t work on “DNS Only”).
  • Pro features – there are major differences between free vs. paid plans in QUIC and Cloudflare. Make sure you understand the differences so you know what you’re getting. There’s also Cloudflare APO, Argo, BunnCDN’s Perma-Cache, and other paid add-ons.
  • True HTTP/3 – QUIC.cloud uses “true HTTP/3” while Cloudflare’s HTTP/3 setting has to pull from HTTP/2 and delivers it with HTTP/3 (explained in NameHero’s YouTube video).
  • Built for LiteSpeed/WordPress – since QUIC.cloud, LiteSpeed Cache, and LiteSpeed servers were built to work together, it should theoretically be a smoother integration.
  • cdnperf.com – QUIC.cloud isn’t listed on cdnperf.com while Cloudflare and BunnyCDN are. StackPath (also by RocketCDN) was removed from cdnperf.com after having issues.
Quic. Cloud pop network
QUIC.cloud PoPs
Litespeed vs nginx http3
LiteSpeed vs. Nginx HTTP/3 performance test (source: LiteSpeed)


2. HTML Caching

I want to emphasize the HTML caching by QUIC.cloud which is similar to Cloudflare’s APO (both cache HTML).

So why does this matter?

When testing TTFB in KeyCDN’s performance test, you’ll notice it gets slower the further away from the origin server (KeyCDN tests your site in 10 global locations). This is because most CDNs don’t cache HTML. Since QUIC.cloud does, you can do a before & after test in KeyCDN and will notice your TTFB is much faster. Which means you can save the $5/month on Cloudflare’s APO. However, you won’t see the same results on QUIC.cloud’s free plan because it only uses 6 PoPs.

Caching HTML makes your TTFB much faster throughout the world


3. Free vs. Standard Plan

QUIC.cloud explains the free vs. standard plan but it can still be confusing between credits, quotas, tiers, PoPs, and features.

Free plan – includes unlimited bandwidth from 6 data centers in the US + Europe. The exact locations are unknown since these are floating PoPs and depend on factors like network traffic, so you don’t know which PoP locations you’re getting. It doesn’t include DDoS protection either.

Standard plan – 83 PoPs, regional pricing, DDoS protection, and certain quotas/tiers which depend on whether your host uses LiteSpeed servers, Enterprise, or are a QUIC.cloud partner.

Quic. Cloud free vs standard plan

PricingCDN costs are 2-8 cents/GB (USD) depending on the region and paid for in credits. QUIC.cloud sometimes has promotional pricing so it may be cheaper depending on the time.

Quic. Cloud cdn pricing

Credits – QUIC.cloud gives you a certain amount of free credits at the 1st of each month. The amount of free credits depend on your tier. Free credits don’t roll over. Once your free credits are used, you’ll need to purchase additional credits from their shop. The more credits you buy, the bigger discount you get. Purchased credits never expire and apply to bandwidth and online services like page optimizations (such as critical CSS + unique CSS generation) as well as LQIP. Quota is just a combination of your free and purchased credits which is applied to your usage.

Quic. Cloud cdn credits pricing

Tiers – monthly free credits depend on which tier you (or usually your host) uses. Basic plans are non-LiteSpeed while LiteSpeed Server and Enterprise depend on which tier your host uses.

Quic. Cloud credits

Non-LiteSpeed servers give you the following free services. LiteSpeed servers get 5x what’s listed, LiteSpeed Enterprise get 10x, and QUIC.cloud partners get 20x. So when comparing LiteSpeed Enterprise vs. OpenLiteSpeed, the amount of freebies you get with QUIC is a big one.

  • Image Optimization – 1000 Fast Queue images
  • Page Optimization – 200 requests
  • Low-Quality Image Placeholders – 100 requests
  • CDN – number of credits equivalent to the cost of 1 GB of traffic through North America


4. Setup Instructions With LiteSpeed Cache

This assumes you already have LiteSpeed Cache installed. You should have also requested a domain key and entered your Server IP in the LiteSpeed Cache General settings. Ryan from NameHero has a video on setting up QUIC (also a solid choice for LiteSpeed hosting). He uses the CNAME method for setting it up, or you can use QUIC.cloud or Cloudflare’s DNS (see step 5).

Step 1: Enable QUIC.cloud CDN in the LSC General settings (leave CDN Mapping off).

Litespeed cache cdn turn on quic. Cloud cdn

Step 2: In your LiteSpeed Cache General settings, click “link to QUIC.cloud.”

Link to quic. Cloud

Step 3: Go to your QUIC dashboard, sign up, and your domain will be added automatically.

Quic. Cloud domain

Step 4: Click your domain and go to CDN → Enable CDN.

Enable quic. Cloud cdn

Step 5: Choose a method for connecting the CDN: QUIC.cloud DNS, Cloudflare DNS, or CNAME (external DNS). QUIC.cloud + Cloudflare’s DNS are both fast, but QUIC.cloud DNS is the easiest.

  • QUIC.cloud DNS: the easiest method is using QUIC.cloud’s DNS but this means you’ll be using AWS’s Route53 which is usually slower than Cloudflare’s DNS. They will copy your DNS records, then click “enable and add records” and they will assign you 2 nameservers. Login to your domain registrar and change nameservers to QUIC’s. Wait for QUIC to detect the change (i.e. 30 min.) and refresh the page. If successful, you’ll see “Using DNS” in QUIC.
  • Cloudflare: LiteSpeed has a video tutorial on this. You will change your CNAME in Cloudflare to the one provided by QUIC.cloud. To do this, go to Cloudflare’s DNS settings and delete the A records for both your www and non-www domain. Next, create CNAME records for www and non-www domains. Make sure you use “DNS Only.” If you have Mail or MX records which use your root domain, you will need to create a subdomain and point the MX record to it. If you have issues, it may be caused by redirects in your .htaccess file.
  • CNAME: copy the address from QUIC.cloud and login to your hosting panel (i.e. cPanel). Go to Zone Editor → Manage and find your domain (www.tomdupuisdemo.com). Click “edit” and change the record (tomdupuisdemo.com) to the URL from QUIC.cloud. Note this only works if your site is using the www version in your WordPress General settings.
Change nameservers to quic. Cloud
QUIC.cloud DNS: you’re assigned 2 nameservers which you’ll change in your domain registrar
Cloudflare cname records with quic. Cloud
Cloudflare DNS: delete A records for www/non-www in Cloudflare and replace with CNAME provided by QUIC
Cpanel zone editor
CNAME: paste QUIC.cloud’s CNAME record in cPanel → Zone Editor

Step 6: Verify QUIC.cloud’s CDN is working. You should see a confirmation message in your QUIC.cloud dashboard (i.e. Using DNS when using QUIC.cloud’s DNS). Eventually, you’ll see traffic is served through QUIC.cloud in the Analytics settings. You can also do an HTTP/3 Test.

Step 7: Configure the “CDN Config” settings in QUIC.cloud. Here are a few tips:

  • Enable static cache (unless you’re using another CDN to cache static files)
  • Enable QUIC backend which lets QUIC connect to your server via QUIC and HTTP/3.
  • The Standard Plan gives you access to security and anti DDoS features with reCAPTCHA and WP Brute Force Defense, restricting XML-RPC, and includes settings for WordPress.

Step 8 (Optional): QUIC.cloud’s IPs are automatically whitelisted as of v.1.7.13, so you shouldn’t need to do anything. But I included the link to their IPs in case you need them.

Step 9: Change from the free plan to the standard plan if that’s what you want to use.

Quic. Cloud cdn plans

Step 10: Select the regions you want to use.

Quic. Cloud cdn regions


5. Image, Page Optimizations, And LQIP

Just a reminder that QUIC.cloud also takes care of image + page optimizations and includes things like critical CSS (CCSS), Unique CSS (UCSS), and LQIP (Low Quality Image Placeholder).

If you want to use these features, enable them in your LiteSpeed Cache settings. Your QUIC.cloud dashboard has a tab for each where you can monitor usage and other details.

Litespeed cache lqip settings
Configure settings in LiteSpeed Cache to use services from QUIC.cloud


6. CDN Config Settings

I’m just adding this to show you just some of the settings in QUIC.cloud (i.e. CDN config).

Quic. Cloud cdn config settings


7. Final Thoughts

This is the ideal setup IMO:

  • DNS: Cloudflare
  • Static assets: Cloudflare or BunnyCDN
  • Then use QUIC.cloud (standard plan) for dynamic assets + other QUIC services

You get the best of all words: Cloudflare’s fast DNS, larger PoP network from Cloudflare or BunnyCDN, then QUIC takes care of HTML caching, HTTP/3, and other services like image/page optimization. Of course it means 3 separate services, but hey, the best doesn’t mean the easiest.


You Might Also Like:


  1. After migrating to Quic.Cloud and testing a TON, there are a few MAJOR issues to watch out for here. The service IS FAST – when it works – but is it worth undetected downtime?

    #1) Almost Invisible Regional downtime.

    If QC’s CDN PoPs cannot reach the origin server, it serves up a Error 520 page that says it cannot reach the origin server. Effectively the site is down.

    From our unfortunate experience, this was happening A LOT. Reason being, the hosting company was blocking quic cloud server IPs frequently. When this happens, you have no visibility and no warning from their systems as to which PoP is down.

    They did add a graph that shows how many 520 errors are occurring, which can give you some idea, but then you have to ask their support staff to check if all PoPs can reach origin – and to my surprise the answer was almost always “all of them are ok… except one” and then they’d give me the IP, I’d go to the hosting company and have them check, and sure enough it’d been blocked for brute force detection, which could actually be just a high crawl rate for the cache warm up service or maybe something else, but the end result is the same, that whole region gets a 520 error page instead of the website. They should have it fail-through to another node when this happens, or bypass CDN somehow, but it doesn’t.

    We had the entire San Francisco region silently go down with no warning for weeks before anyone realized, and if we checked from our browsers it looked fine, and all the while, Pingdom etc had no downtime detection somehow, so it’s verrrrry invisible that it’s happening (until sales drops by a chunk and you start investigating deeper or a customer sends a screenshot of a mysterious error page nobody else is getting).

    What they really need is just an uptime tool page that lists every PoP that is active for your site currently, and whether or not it’s reaching the origin OK or having 520 errors. Just run through them in real time and list them with a green or red light next to them, that would be all it needs. The support techs have this tool via SSH but customers do not have access to it. What would be even better, automate that check hourly or at least daily and auto-email the admin a warning email when there’s an outage. I told them many times I’ll gladly pay extra for that feature since the risk it would bring visibility to is potentially thousands of dollars of losses.

    After looking at the pie chart they added, there was 7k-10k requests per week that were getting 520 errors.. it just wont’ say which nodes are having the issue. So, sor a small business like ours, that’s A LOT of lost potential customers in an unknown location(s).

    In my case this was originally a combination of Siteground + Quic.Cloud. Both companies sort of blamed the other, but both were at fault in different ways. Siteground for blocking valid PoP IPs with their automated anti-bot protection, not whitelisting a major CDN provider when it takes a very short PHP code to do so, and Quic for not providing visibility into downtime or warnings other than having to Slack message their support team everyday and ask…. “Am I down now?” every single day.

    This could theoretically be an issue with any CDN, but after switching to Cloudflare, I have not seen any issues like this yet. Maybe Cloudflare is a larger, more trusted company with a more trusted set of IPs, maybe siteground whitelists their IPs, maybe they monitor these errors and contact hosts for whitelisting, I really don’t know, but I’m just glad my traffic is up again in all the major metro areas and recovering back to what it used to be.

    Quic.Cloud ultimately said they couldn’t reliably integrate with Siteground, which I thought was kind of crazy for a CDN company to say they can’t support a top 10 hosting company. You’d think supporting them all would be a top priority since they represent millions of potential customers. At the same time, without warning you, this issue could go unnoticed indefinitely which is convenient for them to not have to admit to downtime when it’s happening, and just say oh well that’s the hosting company’s fault.

    Bottom line here is if you use Quic Cloud, you should probably be using one of their recommended partners, since those LS hosting companies probably do keep an active whitelist of the QC PoP IPs.

    #2) Inconsistent Caching

    Running a cache check daily, I was surprised that even though TTL is set much longer (1 week I think in most cases), I would get cache misses the first-run almost every day. Even just a few hours later it would repeat this – miss at first, cached on the next request. Slower TTFB at first… then lightning fast. I was running the “Guest Mode” feature that serves up stale copies etc, too, but it didn’t seem to matter.

    Their support seemed to frown on using an NGINX host in combination with their service, and thought that might be why somehow, but I don’t see how that should matter when the PoP should have a snapshot of the page and hold it until TTL expires.

    For a website without tons of constant traffic, that means the first visitor in the last day or even few hours from every city that hits the page probably gets the slow version, which could actually be most users. That… sort of defeats the point of caching with CDN in the first place if it’s not working for the majority of users.

    #3) A lot of setup

    The LS Cache plugin is pretty awesome and speeds up a WP site WAY faster. No doubt.

    But with like 7 tabs of options and more in the dashboard, it’s a lot to set up, leaves a lot of room for error, has it’s own learning curve, and in the end is more work than it seems to need to be when compared to CloudFlare. I can see they have “presets” to sort of shortcut that, which is good but I didn’t get the feeling those should be used if you’re trying to tune your site to be as fast as it can without breaking stuff… so I tried following guides (like this one) and doing all the setup myself, and it was a lot more than anticipated compared to other services. In some ways I do appreciate being able to get under the hood and control things but also some of it seemed a bit convoluted in the workflow, especially with the image services:

    #4) The Image Services / WebP solution is not 100%

    After using the image optimizer / webp feature built into LS Cache plugin, I can say that it did not work 100%. First of all, it runs on “credits” which is another upsell hiding in the service. Still, using the “free credits” monthly that are included, which seemed to be enough to cover a small site’s images OK, not all of the images converted to WebP. Some were missed even though a manual conversion to webp did show a significant savings in file size (if it’s not smaller they say it omits those, which makes sense, but didn’t seem to be the case). In some cases, it works well, and on other sites, it left images broken on page and I’m not sure why and neither was tech support really. The whole process is slow and weird, too, because you have to sort of “gather” images with one button, and then like send them to the service with another button, over and over again, which took me hours. It had an auto-cron version that would essentially automate this process, but I turned that on and left it and came back the next day and it was still sitting where I left it with like 40% of images completed. I manually pressed the buttons over and over for a couple hours and got 100% of images “gathered” and “optimized” or whatever. Seems like stuff they could just do behind the scenes without making it a two-step process.

    Other webP solutions like Matt’s plugins do a better job of just turning it on and having webp, done and done.

    Final Thoughts

    All in all I was impressed with Quic Cloud’s speed, I got one website to go from like a google page speed score of 80s to 99 almost right away after switching over. That was pretty awesome. But I regret moving all my sites over after that because of the invisible downtime / regional 520 errors issue. And, having now used CloudFlare I am impressed with it being basically just as fast, with faster DNS actually, and the setup is very very easy in comparison, though you do have to find your own solutions for things like webp images, and other aspects that were all built into LSCache pretty nicely.

    So, until they provide a PoP status page so that they can bring transparency to their uptime, I can’t recommend this service anymore and would say stick with the leader, CloudFlare.

    But if you do use QC, make sure to use their partner hosts to minimize the chance of their CDN nodes being blocked and you might be OK. Just be sure to check the admin panel stats in your account to get an idea of how many 520 errors are happening and ask their support to check if all nodes can reach your server if you’re getting those.

  2. Hi Tom,

    Great content as always. Really enjoy your blogs and use them a lot for guidance with my new website. Quick (I think) question, what settings do I need to change in order to have static assets with Cloudflare and dynamic with QUIC.cloud? I currently have Litespeed cache set up on a WordPress installation with the QUIC standard plan; Cloudflare DNS is already set up.

    Furthermore, once I have the above setup, can I sue Cloudlfare’s APO for static assets? Would that improve performance although QUIC is taking care of the dynamic assets?

    Looking forward to hearing from you. Keep up the great work!

    • Hey Gio,

      I generally recommending serving both static/dynamic files from the same CDN to avoid things getting messy. But you can change whether static/dynamic files are served from QUIC in their dashboard. In this case, it sounds like you would disable static assets in QUIC, then in your Cloudflare DNS settings, use the orange cloud to make it “proxied” instead of DNS only. I haven’t done this personally… just a guess :)

  3. I’m thinking to switch to quic cloud for both static and dynamic DNS. Any ideas how much traffic the free plan can handle ? And what is the real cost for using the pro version with Quic cloud? Their pricing plan is very confusing to understand

    • Yeah, I had to read it a few times to understand.

      The free plan has unlimited bandwidth but only uses 6 PoPs in US/EU without DDoS protection, and still comes with HTML caching. Paid plan uses all 80 PoPs with DDoS protection.

      You can also get a certain amount of free credits depending on whether your host uses LiteSpeed server or LiteSpeed Enterprise.

      Just to give you an idea, BunnyCDN is $.01 – $.06/GB while QUIC is $.01 – $.04/GB (so it’s probably cheaper but then again, they mark it out like it’s on sale now… but it’s been like that for a while). It’s also needed for page/image optimizations so those require credits too.

      I don’t think it should be much for smaller sites and is comparable to other CDN’s pricing. Maybe test it for a few days and see what it runs you?

      • Also Quic Cloud announced earlier this year that they were doubling their pricing.

        They did double anyone’s existing credits to be fair, but also doubling pricing suddenly feels a bit like a bait-and-switch tactic. They called their original pricing like “introductory pricing” or something to that effect… but it’s like… they still advertised one price and then charged double a few months later after I signed up.

        Still pretty fairly priced but yeah, didn’t like that 100% price increase as a principal

  4. Hi Tom, this is a super amazing guide. I still haven’t build my website yet but I am planning to soon by using LS and QUIC.

    What I don’t understand in step 4 and step 5, is what is the faster method? QUIC.cloud Cloudflare’s DNS? If so, do I have to pay for Cloudflare as well? BEcause it will means double payment: QUIC.cloud Cloudfare. I was thinking that QUIC.cloud is a better to replace Cloudfare not to use them together.

    Thanks a lot in advance for your answer! Merry Christmas


Leave a Comment