Server-Side Caching: Page, Object and OPcache Explained

A dynamic website such as WordPress builds each page on demand. For every visit, PHP runs, the database is queried, templates are assembled and HTML is returned. That work is wasted when a thousand visitors request the same unchanged article. Server-side caching keeps the result of expensive work so it can be reused, and it is often the single biggest speed improvement available to a database-driven site.

There are several layers of caching, and they solve different problems. This article explains the three you will meet most often.

Three layers of caching

Layer 1: PHP OPcache

PHP is an interpreted language. Without help, the server reads your PHP files, converts them to an internal form and executes them on every request. OPcache stores the compiled form in memory, so later requests skip the compile step. It is built into PHP, is typically enabled by default on modern setups, and needs no changes to your site. In practice, you should confirm it is on and keep PHP on a current version, because newer PHP releases generally run the same code faster.

Layer 2: object caching

Object caching stores the results of individual database queries or computed values in memory, often using Redis or Memcached. When WordPress needs the same option, menu or query result again, it reads it from memory instead of asking the database. Without a persistent object cache, WordPress still caches values but only for the duration of one request.

Object caching helps most on sites with logged-in users, memberships, shops and complex queries, because those pages cannot be fully cached. It does little for a simple brochure site that already uses full-page caching. It needs a service such as Redis or Memcached running on the server, which is more commonly available on VPS and dedicated servers where you control the software.

Layer 3: full-page caching

Page caching saves the final HTML of a page and serves it directly on later requests, bypassing PHP and the database altogether. This is where the large gains come from, since the server just hands over a stored file. Typical sources are:

• A caching plugin on a WordPress site that writes static HTML files and has the web server deliver them.
• Web server-level caching, such as nginx FastCGI cache, configured on the server.
• A CDN caching HTML at the edge, for sites where that is safe.

What should never be cached

Page caching is for pages that are identical for every visitor. Exclude:

• Shopping baskets, checkout and account pages.
• Pages for logged-in users, unless the cache can separate them.
• Search results and forms that depend on input or contain security tokens.
• Any page that shows personal data.

A well-configured cache plugin excludes the main WooCommerce pages and logged-in users by default, but verify this after installing. Caching a basket page is a classic way to show one customer another customer's items.

Cache invalidation

The difficult part of caching is knowing when to throw a copy away. If you edit a post, the cached page must be refreshed, and so should archive pages and the home page that list it. Good plugins purge related pages automatically on publish and update. Set a sensible expiry too, so stale copies do not live forever. If changes ever do not appear, clear the cache in the plugin first, then at the CDN, then in your browser, in that order.

How to set it up sensibly

1. Update PHP to a supported version and confirm OPcache is enabled in the PHP settings.
2. Install one page-caching solution. Running two caching plugins together usually causes conflicts.
3. Enable page caching and browser caching, and test the site logged in and logged out.
4. Test any forms, baskets and login pages to confirm they are not served from cache.
5. Add object caching only if you have slow database-heavy pages and the server supports Redis or Memcached.
6. Measure time to first byte before and after, using a free tool, to confirm the gain.

Common signs your cache is misconfigured

• Edits to pages do not show up for visitors for hours.
• Logged-in users see a "logged out" version of the page, or the other way round.
• Contact forms fail with security token errors.
• Different visitors see the same personalised greeting.

Each of these points to a page that should have been excluded, or a cache lifetime that is too long.

Server caching and traffic spikes

Caching also protects your site when a post is shared widely. A cached page costs very little to serve, so the server copes with many more simultaneous visitors than if each had to trigger PHP and database work. Without it, a sudden burst of visits can exhaust the resources of an entry-level plan and slow every page down at the same time.

Choosing hosting that suits caching

Shared and WordPress plans handle most sites well with a page-caching plugin and OPcache. If you run a busy shop or membership site and want Redis or custom server rules, a VPS gives you control over the software stack. Zebra Hosting Cloud offers both, and the VPS plans are the place to start when you need to install your own caching services. VPS servers are delivered by the team within 24 hours.