Client Experience

LiteSpeed hosting — The one performance decision you make once for everybody

Most speed work has to be repeated per client site; caching at the server is the rare exception, which is why it is worth understanding properly.

See WordPress Hosting plans More in Buying Guides

Straight answer first

Server-level caching is the single performance decision a reseller makes once and benefits from across every account, because a cache hit is answered by the web server before WordPress has woken up — no per-site tuning required to get the first and largest improvement.

What follows is the practical version: what you have to do per client site to actually get it, which pages it will never help, how it changes the conversation with a price-sensitive prospect, and the mistake that produces a client with a caching plugin and no caching.

Written by the Hosting Seller staff · Checked 24 August 2026

Free

Migration when clients move in

24/7

Cover behind your desk

Daily

Backups on client accounts

Setup on every plan

The advantage here is architectural. Caching at server level answers the request before WordPress has even started, and plugin caching on a conventional server can only imitate that from further back. For a reseller carrying dozens of client WordPress sites, that difference is not a benchmark — it is the baseline speed of your entire book without you doing anything per site.

LiteSpeed runs on every shelf rather than being fenced behind a premium tier, so every package you build in WHM has it. On the managed WordPress plans — Launch WordPress at $4.19/mo, Pro WordPress at $5.59/mo, Elite WordPress at $9.09/mo — the LSCache plugin arrives with sensible defaults and AccelerateWP with Redis handles the object caching underneath.

What you still have to do per site

Install and confirm the plugin. Genuine LiteSpeed doing the serving is what unlocks everything inside the LSCache plugin, and the plugin is what tells the server which pages are cacheable. On the managed WordPress shelves it arrives configured; on a package you have built yourself, it is a step in your build checklist rather than an assumption.

Verify a hit. Load a page twice in a private window and confirm the second request is served from cache. Twenty seconds per site, and it is the difference between a caching arrangement and a caching plugin. Do it at handover and record that you did.

Set the exclusions. Anything with a per-visitor state — a basket, an account area, a form with a nonce — must not be cached, and a client's plugin stack will introduce these without telling you. Getting this wrong produces the worst kind of bug: intermittent, user-specific and impossible for the client to reproduce while you are watching.

And leave the extras alone at first. Image optimisation and critical CSS wait inside the plugin as optional tuning. Turning everything on at build time gives you no way to identify which setting caused the layout problem the client reports next week.

The pages it will never help

Anything logged in. The WordPress admin, a membership area, a client portal — none of it is cacheable by design, and a client whose complaint is about the back end will not be helped by any amount of page caching. That is an object caching and storage conversation instead.

Checkout and account pages on a shop. A WooCommerce checkout cannot be cached and that is deliberate, which is why a trading client's speed comes down to server resources and object caching rather than to the page cache that rescues a blog.

Genuinely personalised content. If a client's site shows different content per visitor, the cacheable fraction shrinks accordingly. Know this before you promise a speed improvement, because a site that is ninety per cent personalised will not behave like a blog no matter what is underneath it.

AccelerateWP with Redis is the answer to the first two, and it is worth understanding as a separate product from page caching rather than as more of the same. It removes repeated database work from pages that must be built fresh, which is precisely where the page cache cannot reach.

What it lets you say to a prospect

That the baseline is not something you have to arrange. A prospect comparing quotes will usually have one from somebody whose performance story is a plugin they will install on the client's site. Yours is that the caching is in the web server before WordPress starts, on every package, and that the plugin merely tells it what to do.

That it is not fenced off. On plenty of platforms the LiteSpeed advantage lives on a premium tier, which means a price-sensitive client is quietly on the slower arrangement. Here it is on every shelf, so the package you build for a small client has the same serving layer as the one for your best account.

And that modern protocol support comes with it. HTTP/3 and the rest arrive as part of the serving layer rather than as a separate project, which is one fewer thing on a technical prospect's checklist that you have to research before answering.

The mistake that produces a plugin and no cache

Fitting the LiteSpeed Cache plugin to a server with no LiteSpeed underneath it. The plugin installs, the settings screen looks right, the client sees a familiar name, and none of the server-level benefit exists — the plugin falls back to a much weaker mode and the benchmark scores never appear.

Resellers hit this when they carry clients across two suppliers, or when a client arrives from elsewhere with the plugin already installed and everybody assumes it is doing what it did before. The fix is the same twenty-second check: load the page twice and confirm the response is coming from cache.

It also argues for standardising. A reseller running one platform under one set of packages has one caching arrangement to understand and verify. A reseller with clients spread across three suppliers has three, and will eventually explain a performance difference they cannot account for. Consolidating a book is a speed decision as well as an administrative one.

One decision, every account

Almost everything else you do for performance has to be repeated per client site. Server-level caching is applied once, to every package you build, and it is the largest single improvement most client sites will ever get.

SSL comes free with every plan and reissues itself before it lapses, so the other thing that would otherwise need doing per site is handled in the same way.

LiteSpeed on every shelf, not a premium tier
LSCache configured on the managed WordPress plans
AccelerateWP with Redis for the uncacheable half
HTTP/3 as part of the serving layer

Why Hosting Seller

On every plan, as standard

A baseline you set once

Server-level caching applies to every package you build, which is the rare performance decision that does not repeat per client.

Not fenced behind a tier

Your cheapest client package has the same serving layer as your best account, so price sensitivity does not mean slower.

LSCache pre-configured on WordPress plans

The plugin arrives with sensible defaults, so the first and largest improvement needs no tuning session per site.

Redis for what caching cannot reach

AccelerateWP removes repeated database work from basket, account and admin pages that page caching skips by design.

Modern protocols included

HTTP/3 and the rest arrive with the serving layer, which is one fewer item on a technical prospect's checklist.

One arrangement to verify

Standardising your book on one platform means one caching setup to understand, check and explain rather than three.

Price Tags Compared

How we compare with the household names

Typical sign-up and renewal prices across the market, set next to ours — the second number most comparison charts leave off.

What Hosting Seller charges and what it includes, lined up against three rival hosts
Line item	Hosting SellerBest seller	Typical big-brand host	Typical budget host	Typical loss-leader
Entry price / mo*	$2.42/mo	$4–$6	$2–$4	$1–$3
Price at renewal / mo	$2.42/mo	$10–$15	$8–$12	$4–$6
Renewal price on the entry plan is unchanged
SSL on every plan
Site migration included
The entry plan uses NVMe storage
Entry plan gets a backup daily
Live human support, 24/7

*The number in our column is the cheapest plan on our shelf, priced on an annual term and pulled live from the very catalogue that feeds the pricing page, so it cannot drift out of date. Other columns show the ranges shared hosting tends to advertise inside each bracket: introductory rates that normally ask for a one-to-four-year commitment, then climb once that term expires. Naming individual competitors and printing their prices is something we have stopped doing. A figure we cannot re-check on the day you read it has no business sitting in front of you. So compare us with whoever you are genuinely weighing up, and read the renewal line first. That line tells you more than the headline ever will.

First Steps

From choosing to live

1
Put the cache check in your build list
Load the page twice in a private window and confirm the second request is served from cache — twenty seconds, on every site you hand over.
2
Set the exclusions before the client finds them
Baskets, account areas and forms with a nonce must not be cached, and a client's plugin stack will add these without telling you.
3
Leave the optional tuning off at first
Image optimisation and critical CSS are worth having later; enabling everything at build time removes your ability to isolate a problem.
4
Handle the uncacheable separately
Logged-in and checkout pages need object caching and resources, not more page cache — know which conversation you are having.

In the Box

Packed with every plan

LSCache installed and confirmed active on every client site
A cache hit verified in a private window at handover
Cacheability exclusions set for baskets and account areas
Optional tuning left off until the site is stable
Object caching enabled for shops and membership sites
The uncacheable fraction of each client site understood
HTTP to HTTPS forwarding verified alongside the cache
Client instructed not to disable server-level caching
Any inherited caching plugin checked rather than assumed
Your book standardised on one caching arrangement

Across the Counter

Things people ask us all the time

Do I have to configure caching for every client site?

You have to verify it, not tune it. The serving layer is there on every package, and on the managed WordPress shelves the LSCache plugin arrives with sensible defaults. What is genuinely per-site is confirming a cache hit and setting exclusions for anything with per-visitor state. Twenty seconds and a look at the plugin stack, on every handover.

A client installed a caching plugin themselves. Is that a problem?

Usually yes, if it is a second one. Two page caches fighting each other produce intermittent staleness that is very hard to diagnose and impossible for the client to reproduce on demand. Standardise on the one that talks to the server, remove the others, and put a line in your care plan about installing performance plugins without review.

What do I tell a client whose admin is still slow after caching?

That the admin is logged in and therefore never cached, by design, and that the fix is a different one — object caching and resources rather than page caching. AccelerateWP with Redis addresses repeated database work on exactly those pages. Being able to explain why the back end did not improve when the front end did is the difference between a competent supplier and a mystified one.

Is it worth moving a client to a shelf with better caching?

The serving layer is the same on every shelf here, so the answer is usually no — what varies is resources and object caching. A client whose uncached fraction is large, a shop or a membership site, benefits from moving up; a brochure site that is ninety-five per cent cacheable will see almost nothing from more resources. Diagnose which fraction is hurting before you sell an upgrade.

How do I check a client's caching is genuinely working?

Load a page twice in a private browsing window and inspect the response on the second request — if it is coming from cache, the arrangement is real. That check also catches the common inherited failure: a LiteSpeed Cache plugin installed on a server with no LiteSpeed underneath it, which looks right in the settings screen and delivers none of the benefit.

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.

Set the baseline once.

Server-level caching on every package you build in WHM, with Redis object caching for the pages it cannot reach.

See WordPress Hosting plans