Opcode caching, what it saves and when to turn it off

Every PHP request normally reads a file from disk, compiles it to opcodes, then executes those opcodes. The middle step produces the same result every time for the same file. Opcode caching keeps it, so the second request onward skips straight to execution.

You turn it on in one place. Advanced, then Optimization, then the single toggle on the Opcode caching panel. It is on by default here, and the panel says plainly what it does.

What opcode caching actually saves

The cost of compiling is small per request and constant, so the benefit depends entirely on how many requests you serve rather than on how big the site is.

A brochure site with a few visits an hour will not notice. A WordPress installation with a busy admin area, a shop, or anything with heavy plugin code has a lot of files compiled on every request, and removing that cost is the cheapest performance work available because it needs no code change.

It also removes a class of variance. Without a cache, a slow disk read on one request shows up as an occasional slow page with no pattern. With one, the file is already in memory.

What it costs

Memory. The compiled code sits in RAM per PHP process pool, and it does not deal in small numbers, though the default allocation is sized for a normal site.

That is the honest trade. You spend memory you are already paying for to remove work you were doing repeatedly.

Clearing the cache when a change does not appear

There is exactly one, and it is worth recognising because it looks like the server is broken rather than the cache doing its job.

A file changed on disk is not recompiled while the cached version is still valid. If you edit a PHP file over FTP or SSH and the change does not appear, the cache is often why. The panel has a Restart control on the PHP page which clears it, and a PHP version change clears it too, because a restart discards everything compiled under the old process.

You will not hit this when editing through a normal deployment that includes a restart. You will hit it when you edit a file directly, reload the page, see the old behaviour, edit it again to be sure, and see the old behaviour again.

Turning the toggle off is the other way to check, though restarting is faster and leaves you where you wanted to be. The PHP version article covers the Restart control and what else a restart reloads.

Measuring whether any of this helped

Blind performance changes are hard to argue with and easy to imagine. Load the site before and after and read the response time rather than the page. The Server Check tool reports the total request time with the TLS handshake broken out separately, which separates a slow connection from slow code.

When to leave it off

Almost never on a production site. The one legitimate case is a development or staging copy where you are editing files constantly and want every change to appear immediately without a restart step.

That is a reason to turn it off on staging and on for live, not a reason to leave it off everywhere.