Performance Reference
OPcache: confirm it, size it, then stop thinking about it
Something is adding tens of milliseconds to every uncached request and it is not your code.
The short answer
OPcache keeps the compiled bytecode of your PHP files in shared memory, so the interpreter stops reading and recompiling the same source on every single request.
On an application the size of WordPress that is hundreds of files parsed per request that no longer need parsing. It is the cheapest performance win in PHP, it applies to every uncached request including admin screens, and on decent hosting it is already on — so your job is to confirm and size it rather than to enable it.
By the HostingFast team · Reviewed 12 August 2026
0
Hand-waving in this entry
100+
Entries wired to each other
Real
Numbers you can reproduce
Free
To read, no gate
Without it, PHP opens each file, parses it, compiles it, executes the result and throws the compilation away. The next request repeats all of that for the same unchanged files. With it, compilation happens once and the cached bytecode is reused until the file itself changes.
It is enabled by default on our platform and on any host worth using, which makes this a verification exercise. A phpinfo page or the status function will tell you in seconds whether it is running and how well.
Confirming it is on and actually hitting
The status output gives you the numbers that matter: hits against misses, memory used against memory allocated, the number of cached scripts, and the count of restarts. On a warmed-up site the hit rate should be overwhelming — a few misses when a file changes, nothing more.
A poor hit rate on a site nobody is deploying to means one of two things: memory too small to hold everything, or the file count ceiling reached. Both are settings, and both are fixed in seconds once you know which one you are looking at.
The two settings that cause the trouble
Memory allocation is the first. If the cache fills, PHP starts evicting compiled scripts and recompiling them, and you get the cost of caching without the benefit. Watch wasted memory and the restart count: a cache restarting repeatedly under normal traffic is a cache that is too small.
The file limit is the second, and it catches WordPress sites with a long plugin list. If your accelerated-file ceiling is lower than the number of PHP files your application touches, some of them are never cached at all and you will never see it in a hit rate you did not read.
Why the site feels slow just after a deploy
Because the cache is empty. Every file has to be compiled again, so the first requests after a release pay the full cost and the site warms up over the following minutes. That is normal, expected, and worth knowing before you go looking for a regression that is not there.
It is also an argument for deploying at quiet hours on a busy site, and for taking your measurements after the warm-up rather than during it.
What it is not, and where it sits
It is not an object cache. OPcache holds instructions — the compiled form of your code. Redis holds results — what those instructions produced last time. They cover different costs and a properly tuned stack runs both, with neither substituting for the other.
On shared and WordPress plans here it is enabled and sized for you as part of the platform. On a VPS it is yours to configure in php.ini, and it is the highest-yield line in that file. Neighbouring entries: PHP, Cache, Redis and TTFB.
Tuning entries that tell you when to stop
Most performance work has a point past which further effort buys nothing. These entries say where that point is, so you can move on to whatever is actually costing your visitors time.
Per-site PHP version switching sits in the control panel here, so an old application and a current one can share an account without either being held back.
- Diminishing returns marked
- Status output explained field by field
- Panel and php.ini paths both covered
- Written by the engineers on support
Why HostingFast
Standard on every plan
What it removes per request
Hundreds of files parsed and compiled on every uncached request, gone after the first one.
A verification job, not a project
It is on by default on any decent platform. Your task is confirming the numbers, not enabling it.
The status fields that matter
Hits against misses, memory used against allocated, cached scripts, restart count. Four numbers.
Two settings, two symptoms
Memory too small causes evictions and restarts. The file ceiling silently leaves scripts uncached.
The post-deploy dip explained
An empty cache after a release is normal warm-up, not a regression to go hunting for.
Not a substitute for Redis
Instructions versus results. A tuned stack runs both, and neither covers the other's cost.
Quick Start
From order to online
- 1
Read the status output
Hit rate, memory used against allocated, cached scripts and restarts. Four numbers tell you whether anything needs doing.
- 2
Fix the ceiling that is binding
Evictions and restarts mean memory. A hit rate that never reaches the top on a stable site means the file limit.
- 3
Measure after the warm-up
Take timings once the cache has refilled after a deploy, or you will record the warm-up and call it a regression.
Built In
Loaded onto every plan
- SSH, Git and Composer on the developer-focused plans
- Per-site PHP version switching from the control panel
- Staging environments for testing changes before they ship
- DDoS filtering absorbed out at the network edge
- WordPress Toolkit, with updates handled for you
- 99.9% uptime as the target, monitored around the clock
- Your existing site moved over by our engineers, free of charge
- Browser webmail plus IMAP, POP and SMTP for any mail app
- Email addresses that run on your own domain name
- Year one of your domain free when you order annually
Frequently Asked
What people ask us most often
How do I read the status output without guessing?
Four fields carry the answer. Hits against misses gives you the hit rate. Memory used against memory allocated tells you whether the cache is under pressure. Cached script count against the configured file ceiling tells you whether anything is being left out. And the restart count tells you whether the cache is being flushed under normal traffic, which it should not be.
What hit rate should I be seeing?
On a warmed-up site with no active deployments, overwhelming — misses should be rare and correspond to files that genuinely changed. Anything materially short of that means the cache cannot hold your application: either the memory allocation is too small, or the accelerated-file ceiling is below the number of PHP files your plugin list actually touches.
Why is the site slower for a few minutes after a release?
The cache emptied when the files changed, so early requests pay the compilation cost again and the site warms back up over the following minutes. It is normal. Deploy at quiet hours on a busy site, and take any before-and-after measurements once the warm-up has finished rather than during it.
Is it configured for me on these plans?
Yes — enabled and sized as part of the platform on shared and WordPress plans, alongside per-site PHP version switching from the control panel. On a VPS it is yours to set in php.ini, where a sensible memory allocation is the single highest-yield line in the file. If you want the current settings for your account, ask support and they will read them out.
Keep reading
Cache
Five layers between database and visitor, and the header that says which one answered.
Redis
The in-memory store for query results, and the hit rate that proves it is doing work.
Best LiteSpeed Hosting
The buyer's version: what to verify about a LiteSpeed platform before you sign.
Web Hosting
cPanel hosting on NVMe with SSL, migration and a first-year domain included.
Domain Names
Find, register and transfer names, with the first year free alongside annual hosting.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Compile it once, not every request.
OPcache sized for you, per-site PHP switching in the panel, LiteSpeed caching and NVMe on every tier.
View Web Hosting plans