WordPress page caching, set up properly.

Page caching is the difference between a WordPress site that takes 800ms to respond and one that takes 30ms. It's also the cheapest, easiest performance win on the table — and yet it's set up wrong on the majority of WordPress sites we audit. Either there's no cache at all, or there's three caching plugins fighting each other, or the cache is breaking checkout, or the cache is so stale that price updates take six hours to appear.

The right approach is layered. Server-level caching (NGINX FastCGI cache or LiteSpeed cache) runs before PHP even starts and is 5–10x faster than any plugin-based cache. CDN edge caching (Cloudflare APO, Bunny Perma-Cache) pushes that HTML further out so visitors in Sydney get sub-100ms responses from a Sydney node. Plugin caching (WP Rocket, LSCache) sits underneath for hosts that don't support server-level cache. Object caching (Redis) handles the logged-in pages that page caching can't.

The tricky part is bypass rules. WooCommerce carts, checkout pages, account areas and admin must never be served from cache — every visitor must see their own data. We configure precise cookie-based bypass rules: cart cookies, checkout cookies, logged-in cookies, WooCommerce session cookies. Standard URL patterns (/cart, /checkout, /my-account, /wp-admin) are bypassed at the server level. Get any of this wrong and customers see each other's carts or admins see cached pages they can't update.

The other tricky part is invalidation — keeping the cache fresh after content updates. We configure granular purge rules so a product update invalidates that product's URLs, related category pages and the homepage if it's featured there, but not the entire site (which would defeat the cache). Scheduled posts trigger purge at publish time. Comment posting purges just the post's URL. Price updates purge product and category URLs.