Caching means keeping a ready-made copy of something a website has already produced, so it can be handed over again straight away instead of being built or fetched from scratch. On a site whose pages are built by a server, such as WordPress, it is one of the biggest influences on how fast pages respond, and it happens at several layers at once.
How caching works
Without caching, a WordPress page is assembled for every visitor: the server runs code, asks the database for the content, fills in the template and sends the result. That might take half a second or more on modest hosting. With caching, the first visitor’s request does that work and the finished page is saved. The next visitor gets the saved copy, often in a small fraction of the time. Serving a stored copy is called a cache hit; having to build the page is a miss.
The main layers, from the visitor’s device inwards:
- Browser cache: the visitor’s browser keeps images, styles and scripts so later pages reuse them.
- CDN or edge cache: copies held on servers around the country and the world, close to visitors.
- Page cache: complete pages stored on your own server, usually by your host or a caching plugin.
- Object cache: the results of database queries held in memory, which helps pages that cannot be fully cached.
- Code cache: the server keeps its compiled program code ready, so it does not reprocess it on every request.
Every cache needs rules for when copies expire and when they are cleared. Publishing a page or changing a price should clear the affected copies, a process called purging. Some pages must never be cached for everyone: baskets, checkouts, account areas and anything personal to the person viewing it.
Why it matters
Speed is the obvious reason. A cached page reaches the browser sooner, which helps loading measures in Core Web Vitals and keeps impatient mobile visitors on the page. Caching also lets modest hosting cope with a sudden rush of visitors, such as a newsletter going out or a local news mention, because the server is no longer rebuilding the same page hundreds of times.
Getting it wrong has real costs. Stale caches show old prices or offers, which can mislead customers and breach consumer protection rules if the advertised price is wrong. Worse, a cached account or order page can show one customer’s details to another, which is a personal data breach under UK GDPR.
Common mistakes
- Running two caching plugins, or a plugin on top of a host that already caches, so they conflict.
- Failing to exclude basket, checkout and account pages from the page cache.
- Testing speed while logged in to WordPress, which usually bypasses the cache and gives misleading results.
- Switching on every optimisation in a caching plugin at once, then struggling to find which one broke the layout.
- Never purging after edits, so changes appear hours or days late.
- Caching pages with forms for so long that the hidden security tokens expire and submissions start failing.
How to act on it
Ask your host what caching is already in place. Many managed hosts provide page and object caching at server level, in which case you need little or nothing else. If you do add a plugin, use one, configure it deliberately and keep a note of what you changed.
Then test as a real visitor: open a private browser window, load a page twice and look at the response headers in the developer tools. Headers such as x-cache: HIT or cf-cache-status: HIT show a cached copy was served. Check that the basket, checkout and contact form still work, and that a test edit appears after you publish.
Measure before and after with PageSpeed Insights so you know the change helped. Reviewing caching layers and their exclusions is a standard part of my technical SEO service, because a badly set cache can undo most other speed work.