WordPress performance through granular Redis object cache tagging

Last month, I spent about three days debugging a stale data issue on a high-traffic headless project where a simple wp_cache_flush() was killing our TTFB (Time to First Byte) every time a single post was updated. We were seeing cache hit rates drop to nearly zero during peak publishing hours, causing a massive spike in SQL queries that effectively defeated the purpose of our Redis implementation.

If you’re running a headless architecture, you know that wp_cache_flush() is a blunt instrument. It nukes everything in the store, which is the wrong move when you only need to invalidate specific post-type queries or user-meta data. To solve this, we need to move toward granular cache invalidation using tagging.

Understanding the Limits of Default Caching

When you first set up your environment, following a guide like WordPress Performance: Implementing Redis Persistent Object Caching is a great start. It lowers your database load significantly. However, once you move to a headless setup—where the frontend is decoupled—you realize that global clearing is a bottleneck.

We initially tried to implement a custom cache-clearing observer that hooked into save_post. It worked for small sites, but as the dataset grew, the overhead of scanning the cache for keys became non-trivial. That’s when we realized that without a tagging layer, we were essentially blind to the relationships between our cached objects.

Implementing Tag-Based Invalidation with Redis

To achieve granular control, we need to associate cached objects with specific tags (e.g., post_id_123, category_45). While the core WordPress Object Cache API doesn't support tagging natively, we can extend it by wrapping our cache calls in a custom class.

Here is a simplified approach to how we handle this:

PHP
class TaggedCache {
    public static function set_tagged($key, $data, $tags = [], $ttl = 3600) {
        $tags = (array) $tags;
        wp_cache_set($key, $data, 'default', $ttl);
        
        foreach ($tags as $tag) {
            $tag_key = "tag_map_{$tag}";
            $tagged_keys = wp_cache_get($tag_key) ?: [];
            $tagged_keys[] = $key;
            wp_cache_set($tag_key, array_unique($tagged_keys));
        }
    }

    public static function invalidate_tag($tag) {
        $tag_key = "tag_map_{$tag}";
        $keys = wp_cache_get($tag_key);
        
        if ($keys) {
            foreach ($keys as $key) {
                wp_cache_delete($key);
            }
            wp_cache_delete($tag_key);
        }
    }
}

This pattern allows us to trigger TaggedCache::invalidate_tag('post_123') whenever a post is updated. It’s significantly faster than a full flush and keeps the rest of your object caching layer warm.

Why Headless Applications Demand Granular Cache Invalidation

In a headless environment, your frontend is likely relying on the REST API or GraphQL to fetch data. If your cache is global, every update forces the next visitor to hit the database, which can lead to a "thundering herd" problem where multiple concurrent requests attempt to rebuild the cache simultaneously.

By using tags, we ensure that only the specific component—say, a single post view or a category archive—is invalidated. This is a core concept I discussed in WordPress object caching optimization: A guide for senior engineers, where we focus on reducing the total number of round-trips to the database.

Trade-offs and Considerations

Is this perfect? Not quite. Managing tags introduces a small amount of extra memory overhead in Redis, as you’re storing mapping arrays. If your tagging strategy is too granular (e.g., tagging every single object with every taxonomy term), the tag_map keys can become large, which might impact performance during the invalidation phase.

I’ve found that it's better to:

1. Tag by primary entity (Post ID).
2. Use a "version" prefix for broad categories (e.g., archive_v1).
3. Keep the tag map logic outside of the critical path of the hot-read loop.

Before you go down this route, make sure you understand the difference between your persistent and non-persistent layers, as detailed in WordPress object cache: Persistent vs. Non-Persistent Storage Explained. If you're not using a persistent backend like Redis, tagging won't provide the cross-request benefits you're looking for.

Frequently Asked Questions

Does tagging increase memory usage significantly? Yes, it does. You are storing extra metadata in Redis to map tags to cache keys. For most high-traffic sites, this is a trade-off worth making to avoid the performance hit of a global flush.

Can I use this with standard plugins like Redis Object Cache? Most standard plugins don't support tagging out of the box. You'll likely need to write a wrapper or use a library that specifically adds tagging support to the WordPress WP_Object_Cache class.

What happens if a tag-map key gets evicted by Redis? You lose the ability to perform granular invalidation for those keys. Your site will still function, but you might serve stale content until the TTL expires. You should always set a reasonable TTL on your cached objects as a fallback.

Closing Thoughts

We’re still experimenting with how to handle complex dependencies where one post belongs to multiple tags. Currently, we’re leaning toward a hybrid approach where we cache the main object with tags, but keep our API response cache separate. It’s messy, but it’s the reality of scaling a headless CMS. I’m curious to see how the upcoming WordPress core changes to caching might simplify this, but for now, custom tagging is the most reliable way to maintain consistent WordPress performance.