You have two caches running, not one. LiteSpeed Cache (LSCache) sits at the server and caches your full rendered pages in memory. Cloudflare sits at the edge, in data centers around the world, and caches static assets close to your visitors. They don't conflict, and you don't have to choose between them. LSCache handles the expensive part (building the page), Cloudflare handles the far part (getting bytes to a visitor on the other side of the world fast).
If a page looks stale after you publish a change, the fix is almost always to purge Cloudflare's cache from the portal's Cloudflare CDN page (look for Manage CDN on your hosting service).
What each layer actually caches
LSCache is a full-page cache at the server level. When LiteSpeed serves a cached page, the request never touches PHP or the database. It's served straight from memory. On WordPress, this is wired in automatically through the pre-installed LiteSpeed Cache plugin, along with a Redis object cache for database query results. You don't configure any of this yourself. For the full breakdown of what runs on the server side, see How we make your site fast.
Cloudflare's cache is different in kind. It stores copies of your static assets (images, CSS, JS, fonts) in data centers close to each visitor, so a visitor in Singapore isn't pulling files from a server in New Jersey. With proxy mode on, it also handles routing and DDoS protection for your domain. Cloudflare does not know or care that WordPress exists. It caches what HTTP tells it is cacheable, mostly static files, not your dynamic HTML by default.
Put together: LSCache makes the page fast to build, Cloudflare makes the page fast to deliver. A visitor's request hits Cloudflare first, and if proxy mode is on, Cloudflare either serves a cached static asset directly or passes the request through to your server, where LSCache serves the page itself.
Why they don't step on each other
The two caches operate on different content and different invalidation triggers, so there's no real overlap to manage. LSCache integrates with WordPress to keep its page cache current as you publish and update content. Cloudflare has no visibility into that event. It caches assets based on their file type and the cache headers your server sends, and it holds onto them until they expire or you purge manually.
That's the one place the two layers require you to think, at all. A cache-clearing action on WordPress does not reach Cloudflare. If you update a logo, a stylesheet, or any static file and it's not showing the new version, that's Cloudflare's copy still being served at the edge. Purge it from the Cloudflare CDN page in your portal (Manage CDN on your hosting service). There's a Purge cache control there for exactly this.
When you'd want to purge manually
- You replaced an image or CSS/JS file at the same filename (not a WordPress post/page, those are handled through LSCache).
- You changed a Cloudflare setting itself, like
Auto MinifyorBrotli, and want to confirm the new behavior immediately. - A visitor reports seeing an old version of a static asset days after you changed it.
Settings that matter for this stack
You manage Cloudflare entirely from the portal. There's no separate cloudflare.com dashboard, no bringing your own Cloudflare account. The proxy toggle, caching toggle, SSL/TLS mode, and minification settings are all on the Cloudflare CDN page in your portal sidebar. For a full walkthrough of every toggle on that page, see Every Cloudflare setting explained.
A few settings interact directly with the fact that LSCache is already doing page-level caching on the server:
- Proxy toggle: on by default for hosted domains. This is what puts Cloudflare in front of your traffic at all. With it off, LSCache is the only cache in play.
- Caching toggle: controls whether Cloudflare caches assets at the edge on top of what LSCache is doing on the server. Leave it on. There's no downside for a normal site.
- Auto Minify and Brotli: these operate on whatever Cloudflare serves, independent of LSCache's own caching. Running both isn't harmful.
Diagnosing a caching problem
When something looks wrong, work outside-in: Cloudflare first, then the server.
- Hard-refresh in an incognito window to rule out your browser's own cache.
- Purge Cloudflare's cache from the CDN page in your portal and reload.
- If the problem is WordPress content (not a static asset), check that the LiteSpeed Cache plugin is active and that the page isn't excluded from caching in its settings.
- If you're testing a change and don't want to keep purging, turn off the Cloudflare proxy toggle temporarily so you're hitting the origin directly, then turn it back on once you've confirmed the fix.
If you've purged Cloudflare, confirmed LSCache isn't serving a stale page, and a page still won't update, open a ticket from Support in the portal. It's a real person looking at your account, not a bot.