# QUIC.cloud or Cloudflare
Source: https://docs.webgee.com/en/hosting/wordpress/litespeed-comparing-quic-cloud-and-cloudflare



Both put a CDN in front of a LiteSpeed site, and both work with WebGee hosting.
They solve overlapping but different problems. Applies to all shared and
reseller hosting.

## The difference that matters [#the-difference-that-matters]

**Cloudflare caches static files.** Images, CSS, JavaScript and fonts are served
from its edge; the HTML page itself is fetched from your server on every request
unless you add a dynamic-caching product to the plan.

**QUIC.cloud caches the HTML too.** It is built by the LiteSpeed team and talks
to the LiteSpeed Cache plugin on your site, so when you edit a post the plugin
tells QUIC.cloud exactly which pages changed and only those are purged.

For WordPress that distinction is most of the decision. Generating the HTML is
the slow part — the database queries, the theme, the plugins. A CDN that only
caches assets removes some of the transfer time but leaves that work in place.

## Choosing one [#choosing-one]

**QUIC.cloud** suits a site whose value is in page-generation speed: a content
site, a blog, anything where most visitors see the same pages. It also
generates critical CSS per page, which is otherwise a plugin's job and often
done badly.

**Cloudflare** suits a site that needs more than caching — DNS management, a
web application firewall, DDoS protection, bot rules, page rules, redirects at
the edge. It is a broader platform with a much larger network, and for many
sites those features matter more than HTML caching.

<Callout type="info">
  Both offer free tiers, and what each tier includes changes over time. Check
  current plans on their own sites before deciding on cost.
</Callout>

## Running both [#running-both]

It is technically possible — QUIC.cloud serving HTML, Cloudflare serving static
files — and it is rarely worth it.

Two CDNs mean two caches to purge, two places a stale page can hide, and two
suspects when something breaks. Diagnosing a caching problem through two layers
is considerably harder than through one.

<Callout type="warn">
  Pick one unless you have a specific requirement that neither meets alone. The
  most common failure we see is a page that will not update because it is cached
  at a layer the site owner has forgotten about.
</Callout>

If you do run both, be clear about which one is authoritative for HTML, and
purge in order: origin first, then the HTML cache, then the static cache.

## Whichever you choose [#whichever-you-choose]

Neither replaces LSCache on the server. LSCache caches the page at your origin;
the CDN caches it at the edge. Keep the LiteSpeed Cache plugin enabled and
configured — see
[Install and enable LiteSpeed Cache](/en/hosting/wordpress/how-do-i-install-and-enable-litespeed-cache).

## Related [#related]

* [Install and enable LiteSpeed Cache](/en/hosting/wordpress/how-do-i-install-and-enable-litespeed-cache)
* [LiteSpeed Cache presets](/en/hosting/wordpress/litespeed-cache-presets-for-wordpress)
* [LiteSpeed Cache and WP Rocket](/en/hosting/wordpress/litespeed-cache-vs-wp-rocket-a-comprehensive-comparison-for-our-hosting-environm)