Switching Cloudflare on and touching nothing else caches your images, stylesheets and scripts. The pages are still built from scratch on every visit. Getting them served from a copy means telling it to, and that is where the delicate part begins: some pages can never be cached.
|
Caching the wrong page gives you the worst defect a site can have: one visitor sees another visitor cart, or another visitor dashboard. It is not a theoretical risk, it is what happens when you switch page caching on without excluding what follows.
|
The cache here first, theirs second
Our servers run LiteSpeed. That means the cache that pays best on a WordPress site hosted here is the server one, done by its own plugin, because it stores the page before PHP even starts. It is explained in what actually makes a difference, and it comes first.
Cloudflare caching goes on top of that. With both on there are two copies, and the purge order matters: the site first, Cloudflare second, the browser third. Purging and development mode are in Cloudflare: when it helps, how to switch it on, and the cache that fools you.
What is never cached
| What |
Why |
| The login and the dashboard |
They are different for every person and change on every click. Cached, the dashboard stops responding or shows you somebody else. |
| Anything done while signed in |
If the person has a session, the page is theirs. The rule is written against the session marker WordPress leaves in the browser. |
| Cart, checkout and the customer account |
In a shop, the three most personal pages there are. Their names vary with the language and the theme: find yours and exclude all of them. |
| The addresses the site uses to talk to itself |
Those are program calls, not pages. Cached, the dashboard starts behaving erratically. |
| Draft previews |
They are temporary pages by definition. |
|
There is one defect that only shows up hours later, and this is it. WordPress pages carry a single use security code inside them, and it expires. If the page is cached and served to everybody for hours, that code has long expired by the time somebody submits the form. The symptom is a contact form or a comment that always fails, with no explanation, and that works perfectly when you test it right after purging.
|
The order to build the rules in
| 1 |
Switch the site cache on first, with the LiteSpeed plugin, and use the site properly. Most of the gain comes from here.
|
|
| 2 |
Write the exclusions at Cloudflare before switching page caching on. This order does not reverse: exclude first, cache afterwards.
|
|
| 3 |
Exclude on the session marker WordPress leaves in the browser, and on the cart one if you have a shop. That single rule protects everyone with a session without listing pages.
|
|
| 4 |
Exclude on the addresses of the login, the dashboard, the internal calls and the shop pages.
|
|
| 5 |
Only now switch page caching on for the rest of the site.
|
|
| 6 |
Test both faces of the site: an ordinary window signed in, and a private window signed out. They have to look different.
|
|
|
The free plan gives you a limited number of rules. Check how many you have in their dashboard before planning ten. If there are few, spend them on the exclusions rather than the pretty options: a missing exclusion costs more than a missing optimisation.
|
How to recognise a missing rule
| Symptom |
The rule that is missing |
| I sign in and the site shows me as an anonymous visitor |
The session marker exclusion. |
| The admin bar has vanished from the top |
The same one. |
| The cart shows items I did not put there |
The shop page exclusions. Switch page caching off now and only put it back after fixing it. |
| The contact form always fails |
The page is being cached with an expired security code. |
| The dashboard behaves erratically |
The internal calls are being cached. |
| I cannot get into the dashboard |
See the six usual causes before blaming the cache. |
Two options that break more than they fix
They sit next to caching on the same screen and it is tempting to switch them on at the same time. Do not.
| Option |
What it usually breaks |
| Rewriting and combining scripts |
Themes and plugins that depend on load order. The symptom is a phone menu that will not open and a block editor that will not save. |
| Deferring every script |
The same, with even fewer clues about the cause. |
The full list, option by option, is in the options worth having and the ones that cause trouble. And if the site really does break, common WordPress errors.
|
Is the cache showing the wrong site to signed in visitors? Send us the address and the rules you have.
Open a support ticket
|
RECOMMENDED PRODUCT WordPress hosting One-click install, updates handled, and speed that holds up. See plans |
Português
English
