Caching explained: the cheapest way to speed up your site

Picture a waiter who, for every cup of coffee ordered, goes off to pick the beans, roast and grind them. That is WordPress without caching: every page view starts PHP, runs dozens of database queries, assembles the HTML, and only then replies. Caching means you brew it once and the next thousand guests are served immediately.

The layers and what each one solves

• Page cache — finished HTML is stored and served directly. This is the biggest win: TTFB drops from 800 ms to 50-100 ms. For brochure sites and blogs it solves 80% of the problem.
• Object cache — Redis or Memcached store database query results. Essential for shops and membership sites, where full pages cannot be cached.
• OPcache — PHP keeps precompiled code in memory. Enabled server-side and works with no configuration on your part.
• Browser cache — the visitor stores your logo, CSS and fonts locally, so a second visit does not download them again.
• CDN — copies of static files sit on servers worldwide. A visitor in Vienna fetches the image from Vienna, not from your origin server.

What must never be cached

This is where problems usually start. The cart, checkout, account pages and anything specific to a logged-in user must be excluded. The classic failure: a customer adds a product to the basket and sees someone else''s empty basket because a cached copy was served to everyone. Every serious caching plugin ships WooCommerce exclusion rules — check they are switched on.

Configuring it without breaking the site

• Enable page cache only, at first. Walk the site as a logged-out visitor and as a logged-in one.
• Test the contact form and the cart before enabling anything else.
• Turn on minification and CSS/JS combining one option at a time. This is the usual cause of broken layouts.
• Set automatic cache purging on publish, or you will spend an afternoon wondering why edits do not appear.

"I changed something and it does not show"

Almost always caching. Check in this order: clear the plugin cache, then the CDN cache, then hard-refresh with Ctrl+F5. If it still looks old, open the site in a private window — that removes the local browser cache from the equation.

Server-level caching beats plugin caching

A caching plugin still has to start PHP to decide what to serve. Server-level caching (Nginx FastCGI cache or LiteSpeed, for instance) answers before PHP even begins — a further 30-80 ms per request. Our plans ship with server-level caching enabled by default, alongside NVMe storage and a global CDN.

Realistic expectations

A typical uncached WordPress site has a TTFB of 600-1200 ms. With caching configured properly on a decent server, 80-150 ms is normal. It is the one optimisation measured in whole seconds that takes an afternoon to do. If you run WordPress, see our WordPress hosting, where most of this is preconfigured.