NimbleCache features

The whole hit costs one file include, one hash and one file read — not a WordPress bootstrap with the theme skipped.

There is nothing to install alongside it and no command line to open. The one step that can need a hand is a single line in wp-config.php: the plugin writes it, and if the file is locked it shows you the line to paste.

Without that, a traffic spike on an expiring page turns into a hundred identical page builds — which is how a busy morning becomes an outage.

Compressing on every request would throw away most of what the cache just saved.

This answers properly with a 304 and no body, which saves the whole page transfer — a bigger win than the cache hit itself.

Then it fetches the page twice and reports what the server actually did.

When a plugin's cookie is to blame it names the cookie, in the panel and in the response header, a PHP session's PHPSESSID included, and each line opens Diagnostics on an example page. The counts are samples, at most one a minute, keep no visitor data, and can be cleared once the cause is fixed.

The Dashboard lists the last 30 times the whole cache was cleared from this site, with the reason (a menu saved, a plugin updated, the Clear button, or the plugin that asked, marked "probably" when that is worked out from where the request came from), who was signed in (someone who works on the site, never a customer) and the pages removed. Past 10 in a day it names the reason seen most and what to do about it.

Almost none of it is a setting, because a cart page is not cacheable whatever anybody ticks. It is there so you can see the work rather than take it on trust.

Not everything. Emptying the lot because one thing changed is why so many sites run a cache that never warms up. A page that lists posts in a way it cannot work out, such as a news page built with a Query Loop, can be added to the pages it clears with them.

Anyone with something in their cart stops getting cached pages entirely. Price and stock changes purge the product, its category and the shop page the moment WooCommerce reports them.

Real parameters — sorting, filtering, pagination — are kept, so a filtered product list still caches separately. Most caches treat any query string as uncacheable and give up on shops.

Building it from the request's Host header is the classic way a cache ends up serving one visitor a page an attacker wrote.

The same control every other Traslatability plugin uses to answer "where does this apply", so you already know how to work it.

Set one and the pages nobody has needed for longest are cleared first, a few at a time in the background, until it is back under. No cache has ever been improved by filling a hosting allowance.

Diagnostics quotes the header sent by the cache that answered and names that cache where the header says whose it is. Every page NimbleCache clears is passed on to it through Cloudflare's plugin, Nginx Helper, Proxy Cache Purge, SiteGround, Breeze, LiteSpeed Cache, Kinsta or WP Engine, each within what that plugin's own settings allow. The other cache is cleared whole only when you press Clear the whole cache, and a save does not wait for any of it where PHP runs through PHP-FPM or LiteSpeed.

A language held in a cookie — Polylang, WPML, TranslatePress — becomes part of the cache identity, so the first visitor's language does not decide everybody's.

A preloader that takes the site down in order to warm it up has misunderstood the job.

You never have to work out what your hosting can take, because the answer changes and the plugin asks every time.

NimbleCache can start a cached page loading as the pointer rests on its link instead, and never fetches a page it does not cache: not the cart, the checkout, account pages or your exclusions. Signed-in visitors and shoppers with something in their cart get none of it. It builds on WordPress's own speculative loading, and adds the same on WordPress before 6.8.