Every WordPress page re-asks the database the same questions, over and over. NibbleCache detects and benchmarks whichever cache backend your server actually has, connects with zero configuration, and fails safe instead of taking your site down if that backend ever goes offline.
A single page load can trigger dozens of database queries: the same post, the same menu, the same widget settings, fetched fresh every single time a visitor arrives.
NibbleCache helps by remembering the answer in memory so WordPress doesn't have to ask the database again. It detects the fastest backend your server actually has, benchmarks it for real, and fails safe automatically if it ever goes offline.
get_option() or get_transient(), which is
nearly all of them, automatically benefits too, with zero changes needed
on their end. Fewer database queries per page means less CPU, I/O, and
process load on your account, leaving more of your shared hosting plan's
limited resources available for real visitor traffic.
In short, NibbleCache speeds up WordPress at the source, by cutting the database work every page load depends on, not by masking it with a page cache layered on top. That means faster page loads for visitors, and more of your server's resources left free for the traffic that matters most.
NibbleCache is a clean, focused WordPress object cache plugin that automatically detects and benchmarks whichever cache backend your server actually has, including Redis, Relay, Memcached, or APCu, and uses the fastest one, with nothing for you to configure.
It wraps every backend call in a circuit breaker, so a brief outage degrades your site gracefully instead of taking it down, and it implements WordPress's complete object-cache API properly: real pipelined batch operations, atomic writes, non-blocking commands, and tag-based invalidation wired to posts, terms, comments, and WooCommerce.
It also looks after itself: it automatically clears out stale data if your server's cache backend ever changes, and it can spot an abnormal flush pattern from a misbehaving plugin and flag exactly which one is responsible. For WooCommerce stores specifically, high-churn data like cart sessions and product filter counts is excluded from unnecessary overhead by default, verified against WooCommerce's own source code.
On activation, NibbleCache checks every cache backend your host could plausibly offer, benchmarks whichever ones actually respond, and uses the fastest one, in this order:
A PHP extension that speaks the same protocol as Redis but adds an in-memory layer on top, serving repeat reads with no network round trip at all. Most free object cache plugins don't support Relay.
Detected via every Unix socket path your host is likely to use, including CloudLinux CageFS and LiteSpeed Container conventions, plus TCP, with real benchmarked round trips deciding the winner.
Used automatically if Redis and Relay aren't available on your host, with the same zero-configuration approach.
A local, in-process fallback. If even this isn't available, NibbleCache installs nothing at all. Your site behaves exactly as if the plugin weren't there.
Every one of these is live in the current version, not a roadmap item, and not gated behind a paid tier that doesn't exist.
If Redis or Memcached goes unreachable mid-request, whether from a restart or an OOM kill, NibbleCache trips an internal circuit breaker and quietly serves that request without the cache instead of hanging on a connection timeout.
get_multiple(), set_multiple(), delete_multiple(), and add_multiple() are genuine single-round-trip pipelined calls, not a loop dressed up as a batch, which is what most object cache plugins actually ship.
add() uses Redis and Relay's native NX flag, or Memcached's and APCu's own atomic primitives, so two concurrent requests can never both think they were first to write a key.
Traditional object caches leave your server cold after a flush, forcing real visitors to suffer slow page loads while MySQL rebuilds the cache. NibbleCache solves this with a two-phase warming strategy that eliminates cold-start latency entirely.
Wired to post, term, comment, and WooCommerce product events out of the box, with real atomic backend support behind it. It's also the mechanism the optional Bunny Database sync uses to keep multiple servers' caches consistent.
A busy store creates a different caching load than a typical site: every visitor, logged in or not, gets their own cart session, so thousands of distinct, short-lived entries can exist at once. NibbleCache automatically excludes the specific WooCommerce data that doesn't need a database backup copy, verified directly against WooCommerce's own source code, not guesswork.
wc_session_*): safe to lose per visitor, and never mixed up between customers.wc_layered_nav_counts_*): one real, documented case saw this pattern alone responsible for 150MB/sec of database load on a busy store.wc_var_prices_*): a lost entry costs one recalculation, never wrong pricing shown to a shopper.On by default, with nothing to configure. Sites without WooCommerce simply never generate these keys, so it makes no difference either way.
Uses SCAN and UNLINK instead of the blocking KEYS and DEL commands that can stall a shared Redis instance for every site on it. Flushes are scoped to your own site's keys by default, not a blind full-database flush.
See exactly which backend is active, its benchmarked latency, live key counts, an estimated per-site memory usage figure, a random sample of what's actually cached, and hit/miss stats for the current page load.
Running on more than one server behind a load balancer? Connect Bunny Database and every server's cache stays in sync automatically.
Turn on a detailed activity log covering backend detection results, connection failures, and sync activity, directly from the status page. No wp-config.php editing required, and it's capped at 100KB so it never becomes a performance problem of its own.
If another plugin already controls object-cache.php, NibbleCache detects that on activation and leaves it alone entirely, with a clear notice explaining why it's inactive.
This check runs every time detection runs, not just on first install, so it's safe to try NibbleCache alongside an existing setup without risk of silently overwriting something that's already working.
Connects persistently by default and automatically serializes with igbinary when available, for smaller, faster-to-handle cached values.
The serialization decision is made once, at detection time, and stored so every process reads and writes it the same way, including WP-CLI, cron jobs, and hosting-panel tools that often run under a different PHP binary than your site's normal one. A process that can't match the stored decision safely runs uncached for that one request instead of risking corrupted cache data.
Zero-config doesn't mean zero control. "Flush object cache" and "Re-run detection" buttons sit right on the status page for the moments you want to force something rather than wait for it.
No dashboard tour required. This is the entire mental model.
A post, an option, a menu, anything normally fetched from the database.
Already cached? Returned in under a millisecond, no database query at all.
Not cached yet? WordPress fetches it normally and NibbleCache stores it for next time.
Backend unreachable? The circuit breaker routes around it, and the page still loads.
There's no paid tier of NibbleCache holding features back. This is what installing it actually gets you.
| Capability | NibbleCache | Typical Free Plugins | Typical Premium Add-ons |
|---|---|---|---|
| Auto-detects and benchmarks the fastest backend | ✓ | Checks extension exists | ✓ |
| Relay support (in-memory acceleration) | ✓ | ✗ | Rare, often extra-cost |
| Circuit breaker fail-safe on backend outage | ✓ | ✗ | Sometimes |
| Real pipelined batch operations | ✓ | Often loops, not real batches | ✓ |
| Atomic add() (no race conditions) | ✓ | Frequently not atomic | Varies |
| Tag-based invalidation + WooCommerce hooks | ✓ | ✗ | ✓ |
| WooCommerce-aware dual-write exclusions | ✓ | ✗ | Rare, usually manual |
| Proactive post-flush object cache warming | ✓ | ✗ | Rare / Page cache only |
| Multi-server cache sync for load-balanced setups | ✓ | ✗ | Often a separate paid add-on |
| High-concurrency & enterprise site architecture | ✓ | Unstable at scale | Varies |
| One-click debug logging, no config editing | ✓ | ✗ | Varies |
| Ads or upsell nags | None | Common | N/A |
| Price | Free | Free | Subscription or one-time fee |
This is genuinely the whole setup process. There isn't a hidden second step.
From the WordPress Plugins screen, or by uploading the plugin's .zip file directly.
NibbleCache detects and benchmarks your server's available backend automatically on activation.
Settings → NibbleCache shows exactly which backend was detected and live cache stats.
If your site runs on more than one server, connect a free Bunny Database account under Settings → NibbleCache → Bunny Database.
NibbleCache is completely free, open-source, and built without hidden paywalls or bloated features. If it helped improve your database response times and freed up server resources, consider supporting our ongoing development to keep it that way!
Yes. Every feature described on this page is included with the free plugin. There is no separate Pro version, no license key, and no feature paywall.
The only thing that costs money is optional and external: if you choose to connect Bunny Database for multi-server sync, that's a third-party service with its own pricing, entirely separate from NibbleCache itself.
NibbleCache checks for APCu as a last resort. If nothing is available at all, it installs its drop-in nowhere and does nothing. Your site behaves exactly as if the plugin weren't installed for caching purposes.
No. If another plugin already controls wp-content/object-cache.php, NibbleCache detects that on activation and leaves it alone rather than overwriting it, showing a notice that explains why it's staying inactive.
The circuit breaker detects the failed connection and routes around it for a few seconds instead of erroring out or hanging on a timeout. Your site stays up, briefly uncached, and reconnects automatically once the backend is reachable again.
Relay is a PHP extension, fully compatible with Redis, that adds an in-memory layer on top serving repeat reads with no network round trip at all. If it's installed alongside Redis on your host, NibbleCache detects and prefers it automatically, with nothing to configure.
Not by default. All caching happens locally, between the plugin and your own Redis, Relay, Memcached, or APCu, on your own server. The one optional exception is Bunny Database for multi-server sync, and even then only small invalidation events are sent, never post content or user data.
By default, each server's cache only knows about its own edits, so a visitor's experience can depend on which server the load balancer happens to send them to. Connecting the optional Bunny Database integration closes that gap, typically within a minute.
Yes. The core caching layer uses real pipelined batch operations and atomic writes rather than loops disguised as batches, so it holds up under high concurrency instead of degrading as request volume grows. The circuit breaker means a backend blip under load doesn't cascade into a site-wide outage, and non-blocking commands keep one busy site from stalling a shared cache instance for everyone else on it.
For infrastructure running on more than one server, Bunny Database sync is built specifically for that scale: every server's cache stays consistent automatically, old sync data is pruned on a schedule so the sync table never grows unbounded, and the underlying queries are indexed for exactly the lookup patterns the sync process runs, so performance holds steady as history accumulates rather than slowing down over time.
It's a real, verified default, not marketing language. Cart/session data, product filter counts, and variation price caches are automatically excluded from unnecessary database backup writes — each one checked directly against WooCommerce's own class-wc-cache-helper.php source rather than assumed. Applies automatically the moment WooCommerce is active; does nothing on sites that don't run it.
No. Install and activate the plugin; it handles the rest. The status page is there if you're curious what's happening under the hood, but nothing about normal use requires understanding it.
Install NibbleCache and let it find the fastest cache your server already has.
NibbleCache is completely free, open-source, and built without hidden paywalls or bloated features. If it helped improve your database response times and freed up server resources, consider supporting our ongoing development to keep it that way!
Small, focused WordPress plugins built without bloat.