What Cache Invalidation Means
Cache invalidation is the process of deciding when a cached copy is no longer valid and should be replaced with fresh content. It sounds simple, but it is widely considered one of the hardest problems in computer science — and in WordPress, getting it wrong means either serving stale content to visitors or losing the performance benefits of caching entirely.
The freshness vs performance trade-off
Every caching decision involves a trade-off. Aggressive invalidation (clearing the cache frequently) ensures visitors always see fresh content but reduces your cache hit ratio, meaning the server rebuilds pages more often. Conservative invalidation (letting cached copies live longer) maximizes performance but risks serving outdated content — old prices, published-then-retracted posts, or stale inventory counts.
The goal is finding the right balance for your site. A news site needs faster invalidation than a corporate brochure site. A WooCommerce store needs careful invalidation around pricing and inventory changes.
How WordPress caching plugins handle invalidation
Most WordPress caching plugins invalidate on content events: publishing a post, updating a page, approving a comment, or changing a widget. The question is how broadly they invalidate:
- Surgical invalidation — only the specific page that changed is purged. This preserves the cache for all other pages but may miss related pages (like archive pages or category listings that also show the changed content).
- Related-page invalidation — the changed page plus its archives, category pages, tag pages, and the home page are purged. This catches more stale content but clears a larger portion of the cache.
- Full cache purge — the entire cache is cleared. This guarantees freshness but temporarily destroys your hit ratio and causes a thundering-herd problem as every page is rebuilt simultaneously.
Common invalidation mistakes
The most frequent mistake is full-cache purges on every save. Some plugins or configurations clear the entire cache whenever any post is updated, effectively turning caching off for sites with frequent content edits.
Another common issue is forgetting about browser caching. Even after server-side invalidation, visitors may still see cached copies in their browser. Long browser cache lifetimes for HTML (rather than just static assets) can cause persistent stale content that no server-side purge can fix.
Time-based vs event-based invalidation
Time-based invalidation (TTL — Time To Live) expires entries after a fixed period regardless of whether content changed. Event-based invalidation purges entries when specific actions occur. Most WordPress caching setups use event-based invalidation for pages and time-based for object cache entries and browser cache headers.
Further Reading
- Prevent unnecessary network requests with the HTTP Cache (web.dev) — Covers cache lifetime strategies and revalidation mechanisms.