LSCache: server level caching without a plugin doing the work

LSCache stores the finished page inside the web server itself. When the next visitor asks for the same page, the server answers from that copy without starting PHP, without touching the database and without running a single plugin. The plugin you install is a control panel for that cache, not the thing doing the caching.

Where the work disappears

An uncached WordPress request runs a long chain: the server hands off to PHP, WordPress boots, plugins load, the theme runs, the database is queried several times, and HTML is assembled. A cached request stops at the first step.

Why the cache living in the server matters

A caching plugin written entirely in PHP has a structural problem: to decide whether to serve a cached copy, it must first start PHP. Some of the cost you are trying to avoid is spent before the decision is made.

When the cache is part of the web server, the decision happens before the request is handed to the application. Nothing about the site's code runs on a cache hit. That is why a server level cache is not simply a faster version of a plugin cache; it removes a step the plugin cannot remove.

What gets cached and what does not

• Cached: pages that look the same to everyone. Posts, category listings, the front page, static pages.
• Not cached, correctly: anything personalised. A logged in session, a cart, a checkout, a form result. Serving one visitor's page to another would be a bug, not an optimisation.
• Your decision: pages with query strings, search results, and anything you have deliberately made dynamic.

This split is why a mostly editorial site benefits enormously and a mostly logged in application benefits little. Content networks sit firmly in the first group.

The single check worth doing

Load a page twice with a tool that shows response headers. On the second request you should see a header indicating a cache hit, and the time to first byte should drop sharply. If every request reports a miss, something is preventing caching: a cookie set on every visit, a plugin marking pages uncacheable, or a rule excluding more than you intended.

Diagnosing that case is worth its own read: see the rest of this section for why a cached page can still reach the origin.

What it will not fix

Caching hides slow code from visitors; it does not make the code fast. The first request after a purge still pays full price, and if that price is four seconds, every purge hands somebody a four second page. Caching also does nothing for the resource cost of work that happens without a visitor, such as cron jobs and background tasks, which is a limits question rather than a caching one and is covered in Platform and Limits.

The cache documentation is at docs.litespeedtech.com.