Serve your pages before WordPress even loads — and never touch a setting to do it.
The complete list — what each part does and what it is there for.
A cached page is served from wp-content/advanced-cache.php, which runs before the database connects and before a single plugin is read. The whole hit costs one file include, one hash and one file read — not a WordPress bootstrap with the theme skipped.
No Redis, no Memcached, no WP-CLI, no SSH, no server modules and no control-panel access. The cache is files on disk, which is the one thing every host has. Redis makes a fast cache faster; its absence must not make the cache absent.
When a popular page expires, the first request rebuilds it and everyone else is handed the slightly stale copy rather than joining in. 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.
A gzipped copy is written alongside the page when it is stored, so serving it costs nothing. Compressing on every request would throw away most of what the cache just saved.
A returning visitor's browser asks whether its copy is still current on every navigation. This answers properly with a 304 and no body, which saves the whole page transfer — a bigger win than the cache hit itself.
Type an address into Diagnostics and it runs the real decision — the same code the live path runs, not a description of it — names the rule that applied and explains it in a sentence. Then it fetches the page twice and reports what the server actually did.
An Integrations screen that names what it found — WooCommerce, Easy Digital Downloads, WPML, Polylang, TranslatePress — and lists exactly what it does about each. None of it is a setting, because a basket page is not cacheable whatever anybody ticks. It is there so you can see the work rather than take it on trust.
Edit a post and it purges that post, the front page, its categories, tags, author page, archives and feeds. Not everything. Emptying the lot because one thing changed is why so many sites run a cache that never warms up.
The basket, checkout and account pages are never cached. Anyone with something in their basket stops getting cached pages entirely. Price and stock changes purge the product, its category and the shop page the moment WooCommerce reports them.
Tracking parameters are stripped before the lookup, so an advert click and a direct visit share one cached page. 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.
The cache identity is built from your site's own address, frozen when settings are saved. Building it from the request's Host header is the classic way a cache ends up serving one visitor a page an attacker wrote.
Cache everything, or only the front page, or only the kinds of content you tick — posts, pages, products, any custom type — plus category and tag archives, plus individual pages found by searching for them. The same control every other Traslatability plugin uses to answer "where does this apply", so you already know how to work it.
Optional, and off by default because a cache is meant to grow. 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.
A language in the address caches separately by itself. 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.
Optional, off by default, and deliberately unhurried: a few pages every five minutes, taken from the sitemap your SEO plugin already keeps — the list of pages the site itself says matter, with everything you set to noindex left out. A preloader that takes the site down in order to warm it up has misunderstood the job.
Before any background work runs, the plugin reads what the host will actually spare — memory limit, execution limit, load average — and halves its own rate on a small host, or stands down entirely while the server is busy. You never have to work out what your hosting can take, because the answer changes and the plugin asks every time.
Deactivating removes the drop-in and takes WP_CACHE back out of wp-config.php immediately. A deactivated cache plugin with a live drop-in is a site serving pages nothing is purging — the worst state of all, and the one people find a week later.
A hit is a file read and nothing else — no counter, no statistics row, no connection. Everything the dashboard shows is either counted from disk or recorded on the page builds, which had already paid for WordPress.
Activate it on one site or across a whole multisite network. Each site keeps its own settings and its own cached pages, and a site added later is set up on its own.
Every string in the plugin, the admin screens and the licence page is translated into Spanish and French.
Every screen in the plugin arrives without a page load, and every save happens where you are standing. WordPress fetches the whole of wp-admin's CSS and JavaScript again to change one panel; this fetches the panel. The screen you are on is still there while the next one is on its way, and the one you are heading for is usually already in hand — a pointer takes a moment to reach a menu item, and that moment is spent fetching.
A save answers in the corner of the screen, bordered in the colour of what it is telling you and saying what was saved rather than just "Saved". Four seconds, and hovering holds it open. No reload, and no scrolling back to find a notice above the header three hundred pixels from the button you just pressed.
A WordPress admin request spends about a second in its own bootstrap before a plugin gets a word in, and fetching when your pointer arrives only buys back a fraction of it. So the plugin's other screens are fetched quietly while you read the first one — one at a time, only while the browser is idle, and never on a metered connection. By the time you click a tab the answer has been in memory for seconds.