Caching
MagicWP gives each site three cache layers, all on the your site → Caching page. Two of them you turn on and off; the third (OPcache) is always on and needs nothing from you. Flush any of them whenever you need fresh output.
Object cache (Redis)
Caches database queries and PHP objects in Redis so repeated work isn't redone on every request - a big win for dynamic, database-heavy sites.
- Enable Object Cache: toggle it on. The first time, MagicWP installs the Redis cache plugin and wires it up for you.
- Flush Cache: clear the object cache (available once it's enabled).
Page cache (nginx)
Stores fully-rendered HTML pages at the server (nginx). Cached pages are served instantly, without running PHP or touching the database.
- Enable Page Cache: toggle it on.
- Flush Cache: clear all cached pages.
- Change Caching Expiration: set how long pages stay cached (the TTL). Presets range from 1 hour (default) to 1 year (1h, 2h, 4h, 8h, 24h, 7 days, 30 days, 1 year). Saving a new expiration also flushes the cache.
Flushing from anywhere
You can also flush both caches from the site's Tools → Flush cache. Each cache can only be flushed while it's enabled.
OPcache (compiled PHP)
Caches compiled PHP bytecode in memory, so WordPress core, your theme and every plugin aren't re-parsed from source on each request. It sits underneath the other two: the page cache avoids running PHP at all, and OPcache makes PHP faster on the requests that do run.
There's nothing to turn on - OPcache is enabled and tuned on every site. The Caching page shows how it's doing:
-
Hit rate: how often PHP found a file already compiled. Healthy sites sit well above 95%. A dash (
—) just means no requests have been served yet. -
Memory used: how much of the cache is filled.
-
Files cached: compiled files against the maximum.
-
Reset OPcache: throw away every compiled file and recompile on the next request.
You rarely need to reset it
Edits made over SFTP, in the file manager or through wp-admin are picked up automatically within a couple of seconds. Resetting is for the unusual case - deploying code by a route MagicWP doesn't see, or a plugin update that leaves PHP holding a stale file. The first few requests after a reset are slower while files recompile.
Tips
- Enable the page cache for sites that are mostly static - it's the biggest speed win.
- Enable the object cache to cut database load on dynamic sites.
- Leave OPcache alone. It's already working, and resetting it makes the next few requests slower rather than faster.
- Flush after big changes: a theme/plugin update, a bulk content edit, or a search & replace - so visitors see the new version. (Search & replace flushes both caches for you.)
- Use a longer expiration for content that rarely changes; a shorter one if you publish often.
Cached pages can hide recent edits
If a change isn't showing on the live site, flush the page cache (or wait for the expiration). Logged-in/admin views bypass the page cache, so what you see in wp-admin can differ from a logged-out visitor until you flush.