Domain Dictionary · Caches & Clocks
OPcache: a default worth verifying
Half of what runs your site is a setting somebody else chose. Checking is a five-minute habit and it is the same habit everywhere.
The short answer
OPcache keeps compiled PHP bytecode in memory so that every request is spared the work of recompiling the scripts, which hands speed to any PHP site on the machine for nothing. On managed hosting it is switched on and sized for you, which makes it a thing to confirm rather than a thing to configure — and the habit of confirming is exactly the one that serves you on the domain side too.
Left to itself, PHP opens and compiles the source files again for every single request. Across something the size of WordPress that is a great deal of repeated work.
By the Hosting & Domains team · Reviewed 18 August 2026
0
Words left unexplained
100+
Terms in the dictionary
Real
Cases, not hypotheticals
Free
Forever, no account needed
It does the compilation once and keeps handing the result back until a file genuinely changes, which means the saving applies to every uncached request, admin screens included. Even quick hardware feels sluggish without it, and sizing it properly is one of the quiet differences between a platform somebody tuned and one somebody merely turned on.
It is on by default on decent hosting, ours included. Whether it is actually running shows on any phpinfo page, which brings us to the point of this entry.
The check, and the wider habit
Publish a one-line phpinfo page, load it, search for the OPcache section, read whether it is enabled and how much memory it has. Then delete the page, because it tells the world more about your stack than you want published. That is the whole procedure, and it takes longer to describe than to do.
The same instinct is worth carrying into everything you manage. Do not assume the zone contains what you think it does — open the Zone Editor and read it. Do not assume the name renews next spring — look at the expiry date in the client area, or run a public WHOIS lookup and read it from the registry side. Do not assume auto-renew is on, or that the card behind it has not expired. Every one of those is a two-minute check that turns a hope into a fact.
Four caches, and what each of them holds
It helps to be able to place them. OPcache holds compiled code: the instructions for working something out. An object cache such as Redis holds results: what those instructions produced last time. A page cache such as LiteSpeed's holds finished output. And a resolver cache, further out than any of them, holds the answer to which address your name points at.
They are stacked, not alternative, and a fully tuned setup runs the lot. The reason to keep them straight is diagnostic: when something is not updating, knowing which of the four could be responsible saves you clearing all of them in a panic and learning nothing.
How each one knows it is stale
This is where they differ most, and it is the genuinely interesting part. OPcache watches file modification times, so a deploy invalidates it automatically. An object cache is cleared by the application when the underlying data changes. A page cache is purged, by you or by a plugin, when content is published.
A resolver cache is the odd one out: nothing can invalidate it. It expires on the TTL you published, and once an answer is handed out, that promise stands for its full duration whatever you subsequently do. It is the only layer in the stack where the correct move is to plan ahead rather than to press a button, which is why lowering a TTL before a change is such an ingrained habit among people who move names for a living.
On a Hosting & Domains plan
OPcache is enabled and sized as part of the platform, PHP versions are set per site from the control panel so a legacy application and a current one can sit side by side, and LiteSpeed handles the page cache in the server rather than through a plugin. On a VPS the machine is yours: you enable it in php.ini and give it a sensible memory allocation, which is about the highest-yield line in that file.
Nothing here touches your zone. Read on into Redis for the layer above, and into the cache entry for the layer that catches everybody.
Plain definitions for people who own names
This is the reference our own domain team keeps open. Each entry says what the term means, which layer owns it, and how it goes wrong.
Support answers at any hour, and the remit covers the awkward domain questions other registrars hand straight back.
- Panel screens named rather than described
- Recognise-level and operate-level marked apart
- Written out of our own domain support queue
- The timer named wherever a term has one
Why Hosting & Domains
Standard on every plan
This term, pinned down
OPcache defined, placed in the layer that owns it, and shown going wrong — recognise-level after one read.
Nothing invented for effect
No figures we cannot show you in the panel, no test results, no numbers that exist only to sound impressive.
Failure modes, not only definitions
Each entry names the way the thing goes wrong, on the grounds that a fault is usually what sent you looking it up.
The clock named, wherever there is one
Where a term has a timer behind it — a TTL, a grace period, a sixty-day registry hold — the entry tells you how long it runs.
One idea to an entry
No entry tries to be a manual. It defines the term, shows it doing its job, and points at the term you will need next.
Registry and registrar kept apart
Every entry says which company owns the thing being described, because that is the difference between fixing it yourself and reporting it to somebody else.
Quick Start
Order placed to site online
- 1
Confirm the default instead of assuming it
The platform ships this set sensibly. Looking anyway is the whole difference between knowing how your account is configured and hoping about it.
- 2
Open the zone and read it
cPanel's Zone Editor lists every record answering for your name. Five minutes reading your own zone teaches more than an hour of reading about zones.
- 3
Look at the clock
Find the TTL on the record, or the expiry date on the name. Both are plain numbers, and between them they decide how long a mistake gets to last.
Built In
Fitted to every plan
- PHP versions set per site from the control panel
- cPanel, the panel most of the industry already runs
- LiteSpeed caching in the server rather than bolted on by plugin
- Staging copies for trying a change before it goes live
- WordPress Toolkit, with the updates seen to for you
- DNS records you edit yourself, in cPanel's Zone Editor
- Transfer lock and auto-renew switched from your own panel
- Upgrades applied in place, with no migration when the plan changes
- 99.9% uptime as the target, watched around the clock
- No set-up fee, and nothing charged for joining
Frequently Asked
Questions we field again and again
How do I check whether OPcache is actually running on my account?
Publish a small phpinfo page, load it in a browser, find the OPcache section and read the enabled flag and the memory allocation. Then delete the page, because it exposes more about your stack than is wise to leave up. On managed hosting the answer will almost always be yes; the value of looking is in the habit rather than in the surprise.
Does OPcache do the same job as Redis?
No, they sit at different layers and neither replaces the other. OPcache caches compiled code — the instructions for working something out. Redis caches results — what those instructions produced last time. A properly tuned PHP stack runs both. Understanding the split is what stops you switching on the wrong one when a page is slow.
Why can a DNS cache not be cleared the way the others can?
Because it is not yours to clear. Every other cache in the stack lives on infrastructure you or your host control. Resolver caches live on other people's networks all over the world, holding an answer you handed out with a promise attached — the TTL. It expires when it expires. That is the whole reason for lowering a TTL a day before a planned change rather than on the day.
What else on my account is worth checking rather than assuming?
Four things, all quick. Whether auto-renew is on for every name and whether the card behind it is still valid. What your zone actually contains, read record by record in the Zone Editor rather than from memory. Whether the registrant contact address still reaches somebody. And whether the transfer lock is set. Together that is about ten minutes once a year, against a class of problem that is very expensive to unwind.
Keep reading
Web Hosting
cPanel hosting on NVMe drives, with SSL, the migration and year one of the name included.
Domain Names
Search, register and transfer names, with year one free alongside annual hosting.
Changing provider? Work through this checklist beforehand.
A straightforward running order for a migration your visitors never spot: which files travel first, how to bring the mail across without dropping a single message, the right moment to repoint DNS, and the two errors that sit behind almost every outage we get called in to fix.
Hold the name, then point it where you like.
The transfer lock, auto-renew and the auth code all in your hands, and a desk that answers at any hour.
View Web Hosting plans