Hosting & performance
How we make WordPress fast: LiteSpeed Enterprise, LSCache and per-site Redis
The fastest WordPress request is the one that never runs — here is how our stack answers most visits from cache before PHP or MySQL is ever invoked, and what that means for Core Web Vitals.
The fastest request is the one that never runs
A standard WordPress request is expensive. The web server hands off to PHP, PHP boots WordPress, runs the plugins, queries MySQL a few dozen times, assembles HTML, and only then sends bytes back. On a busy site that whole dance happens for every visitor, and it is where almost all of your time-to-first-byte goes.
Our answer is to make sure that, for most visits, none of it happens at all. Across the sites we host — over 100,000 PBN sites plus mainstream managed WordPress — the great majority of front-end page views are served as a pre-rendered full page straight from cache, without invoking PHP or touching the database. The rest of this post is about how the layers that make that true fit together, and where each one earns its place.
The important framing is that these are not competing caches you pick between. Full-page cache, object cache and the CDN edge each catch a different class of request, and the value is in how they hand off to one another.
LiteSpeed Enterprise + LSCache: the full-page layer
Every site runs on LiteSpeed Enterprise with server-level LSCache. When a front-end response is cacheable, the web server stamps it with LiteSpeed cache-control and tag headers, and LiteSpeed serves the complete page directly on the next hit — no PHP process spawned, no MySQL query issued. That is the single biggest lever on WordPress TTFB, because it removes the entire application boot from the hot path.
Because LSCache lives inside the web server rather than in a PHP plugin, it starts working earlier in the request lifecycle and holds pages in a form the server can flush instantly. A cache crawler keeps popular pages warm, so the first visitor after a purge is not the one who pays to regenerate the page. The result is a markedly lower and more consistent TTFB than a plugin-only cache bolted onto a generic stack, where the cache still sits behind PHP.
Our own repo-grade cache plugin ships pre-installed and auto-updated on every site, wiring WordPress to LSCache correctly out of the box. On a non-LiteSpeed origin it simply emits no full-page headers and gets out of the way, while the object cache and exclusion rules keep doing their job — so a migrated site is never left in a broken half-configured state.
Staying fast without serving stale: ESI and smart auto-purge
Aggressive full-page caching has two classic failure modes: serving a logged-in user someone else's page, and serving anyone a page that should have changed. Both are solved at the caching layer rather than by caching less.
ESI (Edge Side Includes) lets us cache the page while punching holes for the parts that must stay live. On a WooCommerce store the catalogue, product and category pages are served as full-page cache for the fastest possible TTFB, while ESI renders the cart fragment, mini-cart totals and account state per request. Cart, checkout, my-account and any nonce or session pages are excluded by default. Shoppers always see their own basket and a working checkout; everyone still gets the storefront from cache.
Freshness is handled by smart auto-purge. Purge hooks fire automatically when content, products, prices or orders change, so the relevant cached pages refresh straight away rather than on a timer, and you can also purge on demand from the dashboard or from inside WordPress. Tag-based purging means editing one post clears that post and its archives — not the entire cache — so a single edit does not cold-start the whole site.
Per-site Redis object cache: for what can't be a full page
Not every request can be a static full page. Logged-in sessions, the WordPress admin, WooCommerce carts, search, and the dynamic fragments ESI leaves live all have to run PHP. For those, the goal shifts from 'skip the application' to 'skip the database'.
Each site gets its own dedicated Redis object cache. WordPress caches the results of repeated database reads — options, transients, post and term lookups, WooCommerce product and session data — in memory, so the same query is not run against MySQL on every hit. The effect is most visible exactly where full-page cache cannot help: faster dashboards, faster carts, and far lower database load under traffic.
The object cache is per-site, not shared, which matters for both performance and isolation. Combined with per-site database throttling, one site's heavy or badly-written queries cannot starve the database for its neighbours. You can read more about how the whole multi-layer setup fits together on our caching feature page, and about the boundaries between tenants under isolation.
The edge and the transport underneath
Cache that lives on the origin still has to cross the network. In front of the server sits the CDN edge, so static assets and cacheable pages are served from a point of presence near the visitor, and the origin stays quiet even under load. For our footprint-free hosting line the same edge is a multi-CDN pool spread across several providers, which serves a footprint goal as well as a performance one; on mainstream WordPress it is simply a fast, well-behaved layer that keeps origins idle.
Underneath, the fundamentals are not skimped. Sites run on NVMe storage with HTTP/3, so the bytes the cache does send arrive over a modern, multiplexed transport with fast storage behind any cache miss. None of these layers is an add-on: LiteSpeed, LSCache, per-site Redis, NVMe and HTTP/3 are the baseline on every plan, not an upsell tier.
What actually moves Core Web Vitals
It is worth being precise, because hosting is often oversold on Core Web Vitals. TTFB is the part of the equation the server owns, and the caching stack above is what drives it down — a cached full page served over HTTP/3 from the edge is about as low as TTFB gets. Because TTFB is the leading edge of Largest Contentful Paint, a fast origin gives every downstream metric a head start it cannot otherwise have.
But LCP, CLS and INP are mostly decided in the browser, by the page itself: an unoptimised hero image, render-blocking CSS and JavaScript, layout that shifts as fonts and ads load, and heavy main-thread work from plugins. No amount of server caching fixes a 2 MB hero or a theme that ships megabytes of JavaScript. Honest hosting makes the server contribution effectively free and consistent, then it is on the site to keep the front end lean.
That division of labour is the useful mental model. We guarantee the request reaches the browser fast and stays fast under traffic; you keep the payload small and stable. Where the two meet — cache warm-up, edge delivery, and keeping the database responsive so dynamic pages do not stall — is exactly where our stack is tuned, and it is what makes managed WordPress on this platform quicker than the same site on a generic host.
Frequently asked questions
Do I still need a caching plugin like WP Rocket?
No. Full-page caching is handled at the web server by LiteSpeed's LSCache, and our own cache plugin — pre-installed and auto-updated — wires WordPress to it correctly, with a per-site Redis object cache behind it. Stacking a second full-page caching plugin on top typically fights the server-level cache rather than helping, so it is not needed and not recommended.
Will caching break my WooCommerce cart or logged-in pages?
No. Cart, checkout, my-account and any nonce or session pages are excluded from cache by default, and ESI keeps the cart fragment and totals live on otherwise-cached pages. Shoppers always see their own basket and a working checkout while the storefront still loads from cache.
How does the cache stay fresh when I publish or edit?
Smart auto-purge fires on the relevant WordPress hooks, so publishing, editing content, or changing a product, price or order clears just the affected pages and their archives — not the whole cache — and a crawler warms them again. You can also purge on demand from the dashboard or from inside WordPress.
Can hosting alone give me perfect Core Web Vitals?
It gives you the best possible TTFB, which is the server's share and a head start for Largest Contentful Paint. But LCP, CLS and INP are largely decided by the page itself — image sizes, render-blocking assets, layout stability and main-thread JavaScript. Our stack makes the server contribution fast and consistent; keeping the front-end payload lean is what closes the rest of the gap.
Related
Try it free for 7 days
Spin up your first sites free for 7 days — no card. Moving an existing network? Your first migration is on us.
Start free