You installed a caching plugin, ticked “enable caching” and the speed test got better. Or it did not, and you are not sure why. Either way, most site owners never see what the plugin is actually doing, so it is hard to tell whether it is set up well, set up badly or quietly doing nothing.
Plugin choice is a separate decision. This post is about the mechanism underneath: page caching in WordPress works in much the same way whichever plugin or host provides it, and once you know how a full page cache decides what to store and when to throw it away, most of the settings explain themselves.
What happens to a request, with and without a page cache
Without a page cache, every visit to every page makes WordPress do the full job. PHP loads WordPress core, your theme and every active plugin, asks the database for the content and settings, runs the template and builds the HTML. Then it sends the result and forgets it. The next visitor, one second later, triggers exactly the same work.
With a page cache, the first visitor still triggers that work. This is called a miss. But the finished HTML is saved, either as a file on disk or in the web server’s memory. The next visitor asking for that page gets the saved copy, a hit, and WordPress barely wakes up. On a typical brochure site the difference in server response time between a hit and a miss is easy to see in any speed tool.
Where the copy is kept depends on the setup:
- Plugin-level caching writes HTML files into a folder inside wp-content. A small file called advanced-cache.php lets the plugin serve them very early in the WordPress loading process. Some plugins add server rules so the web server hands out the file without starting PHP at all.
- Server-level caching is done by the web server or a proxy in front of it: LiteSpeed’s built-in cache, Nginx FastCGI cache, Varnish. Many managed hosts run one of these and give you a purge button rather than settings.
For where the page cache sits among the other layers, see our overview of the different caches on a website. The rest of this post applies to both kinds.
How the cache decides what counts as the same page
A full page cache stores one copy per cache key. The key is usually built from the address, plus a few extra details. Getting the key right is most of the skill.
The address and its query string
/services/ and /services/?colour=blue may produce different pages, so many caches treat anything after the question mark as a different page, or refuse to cache it at all. That is safe, but it has a cost. Visitors arriving from adverts and emails carry tracking parameters such as utm_source, gclid or fbclid. If each of those addresses is treated as a new page, almost every ad visitor gets a miss. Good caches ignore known tracking parameters when building the key. It is worth checking that yours does, especially if you pay for traffic.
Mobile and desktop
If your theme sends the same HTML to every device and lets CSS handle the layout, one copy per page is enough. If the theme or a plugin produces different HTML for phones, for example a separate mobile menu built in PHP, the cache needs a separate mobile copy. Otherwise a phone visitor can be served the desktop page that happened to be stored first. Turn on separate mobile caching only if your site needs it, because it doubles the number of copies.
Cookies
Cookies are how the cache knows a visitor is special. WordPress sets a cookie when someone logs in, and plugins set their own: WooCommerce when a cart has items, comment forms when someone has left a comment, membership plugins for members. A well-configured cache either bypasses the cache for those cookies or keeps a separate copy keyed on them.
What must never go into a full page cache
The rule is simple: if the page shows something that depends on who is looking at it, it must not be stored and served to others. In practice that means:
- Any request from a logged-in user, unless the setup deliberately keeps a separate cache per user role and you understand what that shows.
- Cart, checkout and my account pages on a shop, plus any request carrying a cart cookie. Our post on WooCommerce cache exclusions covers those pages and cookies in detail.
- Form result pages, thank-you pages that show submitted details, and pages behind a password.
- Pages that show location-based prices, currencies or stock, unless the plugin is built to work with caching.
- POST requests, such as a submitted form. Caches normally only store GET requests, which is correct.
- Error pages. A temporary database error that gets cached and served for an hour is a much bigger problem than the error itself.
- The admin area, the login page and REST API or AJAX responses that are personal.
Most caching plugins exclude the standard WordPress and WooCommerce cases on their own. The risk comes from custom pages and plugins added later. After adding a membership, booking or pricing plugin, check that its pages are not being cached.
How long should a cached page live?
Cache lifetime is how long a stored page is used before it is considered stale and rebuilt. There is no single right number, but there are a few things to weigh.
Content changes are usually handled by purging, not by expiry. When you update a post, a good cache clears that page straight away. So the lifetime is mainly a safety net for changes the cache does not notice.
Security tokens set an upper limit. WordPress puts short-lived tokens called nonces into some forms and AJAX calls. By default a nonce stays valid for somewhere between 12 and 24 hours. If a page is cached for longer than that, a visitor can be served a page whose token has expired, and the form, add-to-cart button or newsletter sign-up fails with an unhelpful error. For pages with forms built this way, a lifetime of well under 12 hours is the safer choice.
Quiet sites need longer lifetimes or preloading. If a page is only visited a few times a day, a short lifetime means nearly every visitor finds the copy already expired. Our post on warming the cache with preloading explains how to rebuild pages before visitors ask for them.
Pages with live information need shorter lifetimes. A page that shows “next available slot” or a live score should not be cached for long, or should load that part separately.
Purge rules: what gets cleared when you change something
When you update a post, the page cache should clear more than that one page. The post appears on the home page, the blog index, its category and tag archives, the author archive and the RSS feed. Good plugins clear these related pages automatically. Check your plugin’s purge settings to see which are included.
Some changes affect every page, and no plugin can guess them reliably:
- Editing a menu, footer or sidebar widget.
- Changing theme settings, global colours or fonts.
- Updating a plugin that changes what pages display.
- Changing a price that appears in many places.
After those, do one full purge. Avoid the opposite habit of purging everything after every small edit. Each full purge sends the next wave of visitors to slow, uncached pages.
If there is more than one page cache, say a host cache and a plugin cache, purge order matters: the layer closest to WordPress first, then the outer layers. Otherwise an outer layer can immediately pick up the old copy again from the inner one.
Checking that page caching in WordPress is actually working
Do these checks logged out, because logged-in requests are normally not cached.
- Open the page in a private window and load it twice. The second load should feel quicker, and server response time in a speed test should drop on repeat runs.
- Look at the response headers. In your browser’s developer tools, check the first request in the Network tab. Server caches often add a header showing hit or miss. Cloudflare adds its own, which tells you about the CDN rather than your server.
- View the page source. Many caching plugins add a short comment at the very bottom of the HTML with the time the page was cached. If the time changes on every reload, the page is not being cached.
- Test a page that should not be cached. Add something to the cart, then open the cart in a different browser. It should be empty there.
- Test from an ad-style address. Add ?utm_source=test to a page and check whether it is served from cache.
Write down the server response time before and after. If a hit is not clearly faster than a miss, something is bypassing the cache, often a plugin setting a cookie on every visitor.
Mistakes that make a page cache useless or risky
- A plugin that sets a cookie for every visitor. Some cookie notice, A/B testing or analytics plugins do this. If the cache bypasses on unknown cookies, nobody ever gets a hit.
- Two page caches at once. Pick one: the host’s or a plugin’s. Use the plugin for its other features with its page cache switched off if the host requires that.
- Caching logged-in users without understanding it. Some plugins offer this. It can be done safely, but it is easy to get wrong on shops and membership sites.
- Judging it by the PageSpeed score alone. Page caching mainly shortens the server’s response time. A heavy page still scores badly. Look at the server response figure.
Caching is one part of a broader plan, and our complete guide to website speed shows where it fits beside images, scripts and hosting. If you are still choosing software, read how to choose a caching plugin for your server before installing anything.
Frequently asked questions
Why is my cached site still slow for some visitors?
The visitors may be getting cache misses. Common reasons are a plugin setting a cookie that bypasses the cache, tracking parameters in ad links being treated as new pages, a short cache lifetime on a quiet site, or a recent full purge. Logged-in users and shoppers with items in their cart are also served uncached pages by design.
Will page caching stop my visitor counter or post view counts working?
It can affect counters built in PHP, because a cached page is served without running that code, so the count stops rising. Analytics tools that record visits with JavaScript in the browser are not affected. Many view-counter plugins offer an AJAX or JavaScript counting option meant for cached sites, so switch to that if counts look frozen.
Does a page cache help pages with forms on them?
Yes, the page itself loads faster, but take care with the cache lifetime. Some forms include a WordPress security token that expires after 12 to 24 hours. If the cached page is older than that, submissions can fail. A lifetime of under 12 hours, or a form plugin that refreshes its token, avoids the problem.
Is a page cache worth having if most of my visitors log in?
It helps less, because logged-in requests normally skip the page cache. A members-only site, or a store where most buyers sign in, relies more on a persistent object cache, OPcache and efficient plugins. The page cache still helps the public pages, such as the home page, blog and landing pages that new visitors reach first.
If pages still answer slowly with the cache switched on, or you are unsure what your shop’s cache is storing, the audit in our speed optimisation service checks the cache setup and exclusions first, then lists what to change in order of impact.
Next in this series: Leverage Browser Caching: Cache-Control Headers Explained
