Cache Layers, Measured
Server cache vs plugin cache — why the fastest cache sits below PHP
Two caches can store identical HTML and serve it at very different speeds, because what matters is not what is cached but what has to wake up to serve it. Position in the stack is the whole argument.
The short answer
Server cache, decisively — and the reason is architectural rather than incremental. A caching plugin runs inside WordPress: even at its most efficient, serving a hit means starting PHP and loading part of the application before the stored page is found. A server-level cache such as LiteSpeed's answers from the web server itself; PHP is never started, so the cost of a hit is close to that of a static file.
The refinement that surprises people: on a LiteSpeed platform you still install a plugin — but as the cache's controller, not its engine. The LSCache plugin tells the server what to cache, for how long, and precisely what to purge when content changes, while storage and serving stay below PHP where the speed lives. Configuration in WordPress, execution in the server.
By the HostingFast team · Reviewed 25 August 2026
0
PHP workers woken by a server-cache hit
Early
Plugin caches still load part of WordPress per hit
Tags
LSCache purges precisely, not wholesale
hit
x-litespeed-cache — the header that proves it
Page caching has one idea: build the HTML once, serve it many times. Every caching plugin and every server cache implements that idea. What separates them is the position of the stored copy in the request path — and position dictates how much machinery each hit must wake.
A plugin intercepts requests as early as WordPress allows, which is still after the web server has handed off to PHP and the application has begun to load. A server cache intercepts before the handoff exists. This page measures the difference at both the single-request and the concurrency level, where it grows from noticeable to structural.
Two caches, two request paths
A plugin cache hit travels: web server, PHP process, WordPress bootstrap far enough to reach the plugin's early hook, then the stored file. Well built, that short-circuits most of WordPress — but PHP started, memory was allocated, and a worker was occupied for the duration.
A server cache hit travels: web server, stored page, response. PHP does not start because the request never reaches it. The hit costs what a static file costs, which is why cached TTFB on a LiteSpeed platform routinely lands in the tens of milliseconds where a plugin cache lands in the low hundreds.
Concurrency is where the layers truly separate
PHP workers are a finite pool — a handful per account on shared hosting, a configured number anywhere. A plugin cache spends a worker on every hit, so cached traffic and uncached traffic compete for the same scarce resource. A spike of perfectly cacheable visitors can still exhaust the pool and queue the checkout behind the homepage.
Server-cache hits bypass the pool entirely, absorbed by the event loop that handles static files by the thousand. Under load, the two designs diverge sharply: one degrades as traffic climbs, the other keeps its workers free for the requests that genuinely need PHP. This is the difference that decides how a launch day feels.
Control stays in WordPress either way
The historical argument for plugin caches was intelligence: they live inside WordPress, so they know a post was updated or a product's stock changed. The LSCache design keeps that intelligence and relocates only the engine — the plugin watches WordPress events and instructs the server through cache tags.
Tag-based purging is the underrated half. Update a product and the server flushes exactly the pages carrying that product's tag — not the whole cache, not nothing. Wholesale flushes are how sites end up effectively uncached at their busiest moments; precision purging is how hit ratios stay high while content stays current. ESI extends the model, punching small dynamic holes — a cart count, a greeting — in otherwise cached pages.
Proving the difference on your own site
Single request: curl your homepage twice and read the headers. x-litespeed-cache: hit with a TTFB in the tens of milliseconds is the server layer working; a plugin's comment signature with a TTFB in the hundreds is PHP waking up to serve a file.
Concurrency: step up parallel requests against a cached URL and watch p95. The server cache holds a near-flat line far beyond the point where worker exhaustion bends the plugin's curve. Ten minutes with a load tool makes the architecture diagram unnecessary.
Cache below PHP, controlled from WordPress
Every HostingFast plan serves through LiteSpeed with LSCache enabled, so the fast layer is the default rather than a configuration achievement. Install the plugin, and WordPress gains precise control over a cache it never has to serve.
Your PHP workers are then spent only where PHP earns its keep — logged-in pages, checkout, admin, APIs — while the anonymous majority is answered before the application exists. That division of labour is the platform's speed argument in one sentence.
- LSCache active on every plan — the server layer is the default
- Tag-based purging keeps the cache both hot and correct
- PHP workers reserved for genuinely dynamic requests
- One header — x-litespeed-cache: hit — verifies it any time
Why HostingFast
Standard on every plan
Static-file economics for dynamic pages
A cache hit costs what a static file costs: no PHP start-up, no worker occupied, TTFB in the tens of milliseconds.
Spikes without queueing
Cacheable traffic bypasses the worker pool, so a busy morning cannot starve the checkout of the PHP it needs.
Freshness without flushes
Tag-based purging clears exactly what changed. The hit ratio survives your edits instead of resetting with them.
Quick Start
From order to online
- 1
Identify your current cache layer
Two curl requests and the headers tell you: a server cache announces itself with a hit header; a plugin leaves its signature in the HTML while PHP does the serving.
- 2
Enable the server layer and its controller
On a LiteSpeed platform, install the LSCache plugin and disable competing page caches — one page-cache layer, controlled well, beats two fighting.
- 3
Verify with TTFB and a load test
Cached TTFB should drop to static-file territory, and p95 under stepped concurrency should stay flat. Both take minutes to check and either confirms the move or catches a misconfiguration.
Built In
Loaded onto every plan
- Cache hits confirmed at the server layer — x-litespeed-cache: hit, not just a plugin comment
- One page cache in operation; overlapping caches purge unpredictably and hide misses
- Tag-based purging configured so edits clear pages precisely, not wholesale
- Logged-in, cart and checkout traffic excluded from caching and verified as bypassing
- Object cache running alongside for the requests that must execute PHP
- Cached and uncached TTFB both measured — the gap is your cache's actual value
Frequently Asked
What people ask us most often
Do I still need a caching plugin on a LiteSpeed server?
Yes — but its role changes from engine to controller. The LSCache plugin doesn't serve pages; it tells the server what to cache and, through tags, exactly what to purge when WordPress content changes. Serving stays below PHP. What you no longer need is a plugin that stores and serves pages itself.
Why is a server cache faster if both serve the same stored HTML?
Because the cost of a hit is the machinery woken to serve it, not the HTML itself. A plugin hit starts PHP and loads part of WordPress before returning the file; a server hit returns it from the web server directly. One occupies a scarce PHP worker per request, the other consumes an event-loop turn — the gap widens as traffic climbs.
Where does an object cache fit into this picture?
It is the complementary layer, not a competitor: the page cache serves anonymous visitors without running PHP, while the object cache accelerates the requests that must run — logged-in users, admin, checkout — by keeping repeated database lookups in memory. A fast dynamic site runs both, covering opposite halves of the traffic.
Can running two cache layers cause conflicts?
Two page caches, yes — double-caching produces stale content that survives purges, and diagnosing which layer served a bad page wastes afternoons. The rule: one page cache (the server's), one object cache, and browser caching via headers. Layers should stack vertically, not duplicate horizontally.
How do I confirm the server cache is actually working?
Request a page twice with curl and read the second response: x-litespeed-cache: hit is the proof, and TTFB in static-file territory is the corroboration. A miss on every request usually means a cookie or a plugin is marking pages uncacheable — the header tells you there is something to fix, which is precisely its value.
Keep reading
WordPress hosting
LSCache enabled by default, controlled from the plugin — this page's setup, live.
Web hosting
The LiteSpeed platform underneath: cache below PHP on every plan.
LiteSpeed vs Apache
The server architecture that makes below-PHP caching possible at all.
Redis vs Memcached
The object-cache layer for the traffic no page cache can touch.
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.
Move your cache below PHP
LSCache is on by default across our plans — migrate free, install the controller plugin, and watch cached TTFB drop into static-file territory.
View WordPress hosting plans