Caching means storing a copy of something expensive to produce so the next request can skip the work and serve the copy instead. A web page load usually passes through three separate caches on the way to your screen: the browser cache on the visitor's device, the server cache where your site lives, and (optionally) a CDN cache at the network edge. Each one solves a different problem, and understanding what each layer actually stores clears up most "why is my change not showing" confusion.
On Flashcloud, the server layer is handled for you by default. This article explains what each cache does and where you'd go to look at or clear it.
Browser caching
Every time a browser downloads a file (an image, a CSS stylesheet, a JavaScript file), it can save a local copy so it doesn't have to re-download that file on the next page view. This is controlled by HTTP response headers the server sends along with the file, mainly Cache-Control and Expires.
A typical Cache-Control header looks like Cache-Control: max-age=31536000, immutable, which tells the browser "this file won't change for a year, don't even check." That's fine for a versioned CSS file with a hash in its name, and disastrous for your homepage HTML if you're actively editing it. This is also why "hard refresh" (Ctrl+Shift+R or Cmd+Shift+R) exists: it tells the browser to ignore its local cache and re-fetch everything.
Browser caching is entirely client-side. Nothing you do on the server clears a visitor's browser cache remotely, you can only set headers that tell browsers how long to hold onto a file.
Server-side caching
This is where the real performance work happens, and where hosting infrastructure matters most. Instead of rebuilding a page from scratch on every request (running PHP, querying a database, assembling HTML), a server cache stores the finished output and serves that instead.
Flashcloud runs LiteSpeed Web Server with LSCache on shared and WordPress hosting. LSCache is a full-page cache that sits ahead of PHP entirely: when a page is cached, the request never touches PHP or your database, it's served straight from memory. Logged-out visitors get the cached version; logged-in users and admin pages bypass it automatically, and the cache clears itself when you publish or edit content. WordPress installs add a second layer on top: a Redis-backed object cache that stores database query results, so even the parts of a page that can't be fully cached still skip repeated lookups.
You don't configure any of this to get the baseline benefit. It's on by default the moment your site goes live. The full breakdown of what runs and why is in How we make your site fast and The cache stack we ship with every WordPress install.
If you've made a change and it's not showing up, server cache is the first place to check. On WordPress, open wp-admin → LiteSpeed Cache and use the purge option before assuming something's broken.
CDN caching
A CDN adds a third layer: copies of your static files cached on servers spread around the world, so a visitor in Sydney doesn't have to wait on a round trip to a server in New Jersey. This matters most for images, CSS, JS, and fonts, files that rarely change and are identical for every visitor.
Flashcloud uses Cloudflare as its DNS provider, which gives every site Anycast DNS and DDoS protection at the DNS layer without any setup. Turning on Cloudflare's proxy mode (the "orange cloud" on a DNS record) goes further: it puts Cloudflare in front of your site to actually cache and serve content from the edge, not just answer DNS lookups. That's worth doing when a large share of your traffic is geographically distant from your datacenter, or when you're serving a lot of static assets. Setup and tradeoffs are covered in Setting up a CDN with Cloudflare.
CDN caching is a genuinely separate cache from server-side caching. Purging LSCache doesn't touch anything cached at Cloudflare's edge, and vice versa. If a change still isn't visible after a server-side purge and you have proxy mode on, that's the next place to check.
Why layers can disagree
Each layer has its own idea of how long content is "fresh," which is exactly why a page can look updated to you and stale to someone else: your browser might have an old copy, the server cache might be stale, or an edge node might not have picked up the change yet. Fixing a stale-content issue means figuring out which layer is holding the old version, not just repeating "clear cache" and hoping.
A rough diagnostic order: hard-refresh your browser first (rules out the cheapest layer), purge the server cache next (LiteSpeed Cache plugin on WordPress), then check whether Cloudflare proxy mode is on and purge there if so. If your site is generally slow rather than showing stale content, that's a different problem, see My WordPress site is slow for plugin and image-weight culprits that caching alone won't fix.
When to contact support
If you've purged the WordPress cache and checked Cloudflare proxy status and content is still stale, or you're not sure which layer is holding an old version, open a ticket from Support → New ticket in the portal. It's a real person on the other end, not a bot, and they can check server-side cache state directly.