Every cache trades a little memory or disk for a lot less work. The four below stack on top of each other, and most slow sites are missing two or three of them.
1. Server-side page cache
The big one. After the server builds a page, it saves the finished HTML and serves that copy to the next logged-out visitor instead of building it again. A request that took 400 ms now takes 40.
It runs at the web server (LiteSpeed LSCache, NGINX FastCGI cache, Varnish) or via a plugin. Server-level is faster and survives plugin changes. This is the cache that lets a modest plan handle real traffic.
2. Object cache (Redis or Memcached)
Pages that cannot be page-cached, like a logged-in dashboard or a cart, still run code and hit the database. An object cache stores the results of repeated database queries in memory, so the second, third and hundredth time a query is needed, the answer comes from RAM.
This is what speeds up membership sites, stores and busy admin areas. Ask whether Redis is included or an add-on.
3. PHP OPcache
PHP is compiled every time it runs. OPcache keeps the compiled version in memory so that step is skipped. It is a simple on or off setting, it should always be on, and any decent host enables it by default. Worth checking, because a misconfigured host that leaves it off makes every request slower for no reason.
4. Browser cache
The visitor's browser stores your images, CSS and fonts locally, so the second page they view does not re-download them. It is controlled by response headers your host or CDN sets. Long cache lifetimes on static files are close to free speed for returning visitors.
| Cache | Lives | Helps | Ask the host |
|---|---|---|---|
| Page cache | Web server or plugin | Logged-out traffic, spikes | Which one, and is it server-level |
| Object cache | Redis or Memcached in RAM | Logged-in, carts, admin | Included or an add-on |
| OPcache | PHP, in memory | Every PHP request | On by default (it should be) |
| Browser cache | The visitor's browser | Returning visitors | Sensible cache headers set |
The catch with caching: a cached page can be stale. Good setups clear the relevant pages automatically when you edit content or someone buys something. Test that publishing a change shows up straight away, and that prices and stock are never served from a stale cache.
What "fast host" often really means
When a host benchmarks well, it is usually because LSCache or an NGINX cache is doing the heavy lifting, Redis is available, and OPcache is tuned. The raw hardware matters less than whether these are set up and switched on. You can put the same stack on a cheaper host and get most of the way there.
HM Towhidul Islam · Senior Technical SEO Lead
Check the response headers on your own site right now. If you do not see a cache hit header on a normal blog post while logged out, your page cache is off or broken, and that is almost certainly why the site feels slow under traffic.
Illustrative example
A membership site that blamed the host
Picture a site where the public pages were fine but the member dashboard took three seconds. The owner was about to move to a pricier host.
The dashboard could not be page-cached, and there was no object cache, so every load ran dozens of uncached database queries. Turning on Redis brought it under a second on the same plan.