OPcache

WordPress is written in PHP. To answer a request, PHP has to read each file involved, compile it into instructions it can run, and then run them, and they are the same files every time.

PHP's manual says OPcache "improves PHP performance by storing precompiled script bytecode in shared memory, thereby removing the need for PHP to load and parse scripts on each request." It has been bundled with PHP since version 5.5.0. "Opcode cache" is the general name for this kind of cache, and it is the name WordPress uses on its screens.

OPcache is the only one of a site's caches that stores code. A page cache stores finished pages, and a page served from one never reaches PHP. The object cache and transients store data that the code produced. A CDN stores copies of files on other servers. WordPress's hosting handbook says an opcode cache is particularly helpful for dynamic content and logged-in traffic, where full page caching is less effective.

Where you meet it

• Site Health, Status tab. Go to Tools, then Site Health. Since WordPress 7.0 the tab shows "Opcode cache is enabled" among the passed tests, or "Opcode cache is not enabled" as a recommendation.
• Site Health, Info tab. The Server section has a row named "Opcode cache" that reads "Enabled", "Disabled" or "Disabled by configuration". When it is on, more rows follow: "Opcode cache memory usage", "Opcode cache interned strings usage", "Opcode cache hit rate" and "Is the Opcode cache full?".
• The server's PHP settings. opcache.enable switches it on, and is on by default. opcache.memory_consumption sets its memory, 128 megabytes by default. opcache.max_accelerated_files sets how many files it can hold, 10000 by default. WordPress's hosting handbook treats these as the host's to set and to watch.
• Not on the command line. opcache.enable_cli is off by default, so WP-CLI runs without OPcache and cannot tell you about the website's.

What goes wrong

• It is off. Every request compiles WordPress and every active plugin from scratch. See how to find the cause of a slow WordPress admin and how to reduce server response time.
• It is full. The handbook says that when the cache runs out of memory, or reaches its limit of scripts, a site spends more time recompiling PHP files. "Is the Opcode cache full?" then reads "Yes". Ask the host to raise the two limits above.
• Old code keeps running after a change. By default OPcache checks every 2 seconds whether a file has changed. A host can switch that check off with opcache.validate_timestamps. The manual says OPcache then has to be reset, or the web server restarted, before a changed file takes effect. An update that seems not to have applied can be this.
• The PHP underneath is old. OPcache is part of PHP, so it is only as current as the PHP version the host runs. The WordPress and PHP end-of-life checker shows whether yours still gets security fixes.

How to tell whether a fault is the host's or the site's includes how to write to the host.