Your website's cache, explained simply
Why your site is fast one day and slow the next, why a change takes time to appear, and what the caching layers between your content and your visitors actually do. No jargon, with the advantages and limitations of each level.
Why cache at all?
Without caching, every visit forces the server to rebuild the entire page: read the database, assemble the template, generate the HTML. It's like a restaurant cooking the recipe from scratch for every customer, even when ten people order the same dish. The cache is the portion already prepared: it's served in a few milliseconds.
The result: a faster site for your visitors, a server that handles traffic spikes without flinching, and a better signal sent to Google — speed is one of its ranking factors. The trade-off: a cached copy can become stale, and that's where trouble starts when the cache is poorly managed.
The path of a visit and its bottlenecks
The six caching levels, one by one
For each one: what it is, its advantages, its limitations and why we use it.
1. The browser cache
Your visitor's browser keeps a local copy of images, stylesheets and scripts, sometimes of entire pages.
- Advantage: the second page visited loads almost instantly, without touching the server.
- Limitation: we don't control the visitor's device — a local copy can outlive your updates.
- Why we use it: short lifetimes on HTML, long ones on versioned static files — the best of both worlds.
2. The CDN (content delivery network)
Servers distributed around the world keep a copy of your site as close as possible to each visitor. We use Cloudflare.
- Advantage: speed everywhere, protection against traffic spikes and some attacks.
- Limitation: a local purge that isn't propagated to the CDN leaves stale content in circulation.
- Why we use it: our purges propagate automatically to the CDN — both layers stay in sync.
3. The page cache
The complete HTML of each page is kept ready to serve, without WordPress recomputing it or querying the database.
- Advantage: the most spectacular gain — the page ships in a few milliseconds, even under heavy load.
- Limitation: it's the trickiest level to invalidate — a modified or unpublished page can stay visible if the purge is wired up incorrectly.
- Why we use it: our smart purge clears only the pages affected by a change, and personalized content (cart, accounts) is never cached.
4. The code cache (OPcache)
The server keeps WordPress's PHP code already compiled in memory, instead of rereading and retranslating it on every visit.
- Advantage: speeds up everything, including what can't be cached elsewhere (cart, forms, admin).
- Limitation: invisible and maintenance-free for you, but a misconfigured server can serve old code after an update.
- Why we use it: enabled and monitored on our hosting — it's a free, permanent gain.
5. The object cache
The results of database queries (settings, menus, content) are kept in memory, with Redis when the site warrants it.
- Advantage: takes pressure off the database — decisive for stores and member areas, where every page stays dynamic.
- Limitation: if a piece of software writes directly to the database without notifying the cache, the cache rereads a stale value.
- Why we use it: our custom code systematically invalidates the affected entries after every direct write.
6. The data cache
Information that is costly to obtain — reports, calls to external services, feeds — is kept with an appropriate expiry date.
- Advantage: avoids asking an external service for the same thing a hundred times, when it's often rate-limited or billed per call.
- Limitation: a piece of data can lag behind reality until it expires.
- Why we use it: each piece of data gets a lifetime that fits it — a few minutes for a balance, a month for a stable value.
How we keep these layers under control
A poorly managed cache does more harm than good: stale pages, invisible changes, unpublished content still online, a site that collapses after a full purge. Our system applies proven safeguards: targeted purging that clears only the affected pages, automatic propagation to the CDN, controlled warm-up after purges to avoid a slow first visitor, protection of personalized content, and integrity checks before serving any copy.
These mechanisms are part of our maintenance plan and our WordPress hosting. Measured speed is also among the 176 checkpoints that our system monitors continuously — built in Drummondville, for websites across Quebec.
Is your site properly cached?
Our free analysis measures your site's real speed and spots missing or misconfigured layers.
Questions fréquentes
Why don't my changes show up on the site?
A caching layer is probably still serving the old copy: browser, CDN or page cache. A hard refresh (Ctrl+Shift+R) handles the browser case; for the rest, the purge has to be triggered on the site side. On the sites we maintain, purging the affected pages happens automatically with every publish.
Should I clear the whole cache whenever something's off?
Rarely, and it's often counterproductive: a full purge forces the whole site to be rebuilt at once, which slows it down for the next visitors. A targeted purge of the affected pages is enough in the vast majority of cases.
Can caching harm an online store?
Poorly configured, yes: a cached cart or price can show up for the wrong visitor. That's why personalized content — cart, customer account, forms — is excluded from the page cache; the store instead relies on object caching, which speeds things up without freezing content.
Is a caching plugin enough?
A plugin generally covers only one layer, the page cache, and leaves you responsible for its invalidation and its consistency with the CDN. The best results come from all the layers tuned to work together — that's what our hosting and maintenance plans put in place.
Does caching improve search rankings?
Indirectly, yes. Speed is part of Google's ranking signals via Core Web Vitals, and a fast site reduces abandonment. Good caching is one of the most cost-effective speed levers.