Trade Terms
Opcache — Nobody Asks About This One, and It Sets the Floor Under Everything
No client will ever ask about it, and it quietly decides how many accounts your tier can carry comfortably.
Straight answer first
OPcache keeps compiled PHP bytecode in memory so scripts skip recompilation on every request, and for a reseller its significance is density: it is a large part of why a modest tier can carry a long client list without the machine noticing. Nobody will ever ask you about it.
Practically that makes it something to confirm rather than configure. It is enabled by default on decent hosting, including here, so your job is knowing it is on, knowing what it does not cover, and recognising the rare client application that needs something more.
Written by the Hosting Seller staff · Checked 24 August 2026
0
Questions we do not duck
100+
Entries, cross-linked
Real
Kit named as it ships
Free
To read, and to quote from
Left alone, PHP reads and compiles the source files afresh for every single request. OPcache does that work once and reuses the result until a file actually changes. On a codebase the size of WordPress the saving lands on every uncached request, admin screens very much included.
For a reseller carrying thirty or forty client sites, that saving is multiplied by every one of them. It is the least visible line in the entire performance stack and one of the largest contributors to whether your accounts feel quick or merely adequate.
Why it matters to the person paying the wholesale bill
Every client site you host runs PHP, and every PHP request either recompiles the codebase or does not. Multiplied across a client book, that difference decides how many accounts a tier carries before anything feels sluggish — which is the same thing as deciding your margin per account.
It is worth understanding for that reason alone. Resellers who know why their density works can size a tier confidently; resellers who do not tend to over-buy capacity because a site once felt slow for a reason they never identified.
Confirming rather than configuring
On managed platforms it is enabled and sized as part of the build, so the useful skill is verification. A phpinfo page on any client account will show you whether it is active and how much memory it has, and that check takes about a minute.
Do it once when you take on a new supplier or a new tier, not once per client site. This is a platform property rather than an account setting, and treating it as something to fiddle with per client is a good way to waste an afternoon.
The one time it becomes a client conversation
A client running an unusually large custom application — a framework doing heavy autoloading, a build process that rewrites files constantly — can occasionally need memory or invalidation behaviour beyond what a shared platform provides.
That is a root-access conversation, which means a VPS with php.ini in your own hands. It is rare enough that you should treat it as a genuine requirement when it appears rather than as a category of client to plan for.
Where it sits in the explanation you give clients
Not in the feature list. Nobody buys hosting because of a bytecode cache, and itemising it makes a package page read like a specification sheet nobody finishes. It belongs in the explanation of why the platform is quick, if a technical contact asks how.
The client-facing version is simpler: the server keeps the site's code ready to run rather than rebuilding it for every visitor. One sentence, accurate, and it stops there.
Every term, costed
A trade file for people who resell hosting. Which terms belong on a package page, which belong in a client call, and which quietly decide your cost per account.
Per-site PHP versions are chosen from the panel, so a client running an old application and one running a current framework can sit side by side on the same reseller plan.
- Written for the person who sends the invoice
- Density explained, since it decides your margin
- Verification steps, not configuration advice
- People to escalate to, round the clock
Why Hosting Seller
On every plan, as standard
The mechanism behind your density
Every client site runs PHP. Whether it recompiles per request decides how many accounts a tier carries comfortably.
A one-minute verification
A phpinfo page shows whether it is active and how much memory it holds. Check per platform, never per client.
Not a feature-list item
Nobody buys hosting for a bytecode cache. Keeping it out of your package copy keeps that copy readable.
A client-facing sentence that works
The server keeps the code ready to run rather than rebuilding it per visitor. Accurate, brief, and it ends there.
The rare genuine exception
A huge custom application with heavy autoloading is a root-access conversation, not a shared-platform tuning exercise.
Confidence when sizing a tier
Understanding why density works means you buy the capacity you need instead of over-buying after one unexplained slow afternoon.
First Steps
From choosing to live
- 1
Verify it once per platform
A phpinfo page on any account tells you it is active and how much memory it has. That is a platform check, not a per-client task.
- 2
Keep it out of the package copy
It belongs in the answer to a technical question, not in a feature list that a buyer will stop reading halfway down.
- 3
Escalate the genuine exception
When a client's application really does need different memory or invalidation behaviour, that is a root-access requirement and should be quoted as one.
In the Box
Packed with every plan
- PHP versions picked per site from the panel
- NVMe SSD underneath and LiteSpeed caching in front
- WHM for you, and a cPanel of their own for every client
- Overselling switched on from the first account you create
- Room for up to 500 cPanel accounts on the top tier
- Staging copies so client changes get tested before they go live
- SSH, Git and Composer on the plans built for developers
- Daily backups taken across every client account
- Nothing charged at setup on any reseller tier
- Real people answering, for you and for your clients
Across the Counter
Things people ask us all the time
Is this something I need to configure per client account?
No, and treating it that way wastes time. It is a platform property, enabled and sized as part of the build. Verify it once when you take on a tier or a supplier by loading a phpinfo page, note the memory figure, and move on. There is nothing per-client to tune and nothing per-client that can go wrong.
Should it appear in my hosting package feature list?
Leave it out. Buyers do not choose hosting on bytecode caching, and a package page that itemises internals stops being read. Keep a one-line explanation ready for the occasional technical contact who asks why the platform is quick, and let the feature list carry things a client can actually evaluate.
A client's application is still slow with it enabled. What now?
Then the time is going somewhere else — database queries, external API calls, or work the application genuinely has to do per request. Compiled-code caching removes compilation, not computation. Measure the uncached response, find where the time actually sits, and quote for the part that is fixable.
How does this relate to the object cache I keep hearing about?
Different layers doing different jobs. One caches compiled code, which is the instructions for working something out. The other caches results, which is what those instructions produced last time. A properly tuned stack runs both, and neither substitutes for the other — worth knowing when a client's developer asks.
Read next
Web Hosting
The mainstream package your clients recognise: cPanel, NVMe disks, SSL and the migration included.
Domain Names
Names to register and transfer for clients, with year one free on annual hosting.
Moving your site to another host? Start with this checklist.
A step-by-step order of work for a move your visitors never spot: which files to copy first, how to carry email across without losing one message, the right moment to repoint DNS, and the two mistakes behind nearly every hour of downtime people ring us about.
Take the counter, keep the margin.
Per-site PHP versions, server-level caching and room for up to 500 client accounts — on tiers you brand, name and price yourself.
See Web Hosting plans