Server-Level Caching for Dynamic E-commerce Pages

Choosing the best server-level caching strategies for dynamic e-commerce pages means solving a specific problem: your product grid can be cached for everyone, but the cart, the logged-in price and the stock badge cannot. Most caching advice stops at “install a page cache plugin,” which is exactly where store owners get burned by stale prices and leaked sessions. Below is how we layer caching on an e-commerce server so dynamic content stays correct while 80 to 95 percent of requests never touch PHP.

Why standard page caching breaks on a store

A blog page is the same for every visitor, so a full-page cache is trivially safe. A store page changes based on session, cart contents, currency, customer group pricing, inventory level and sometimes geography. When you cache that whole response as one blob, someone eventually sees another shopper’s cart total.

The usual reaction is to exclude every dynamic template from the cache: cart, checkout, my-account, and often the whole shop archive. Now the pages that earn revenue are the slowest pages on the site, with a 900 ms to 2.5 s time to first byte on a busy afternoon. The better answer is to cache almost everything and carve out the small dynamic fragments.

Understand the layers before you pick a strategy

People borrow the CPU vocabulary of L1 through L4 cache when they talk about system design, and the analogy is useful. A web request passes through a stack of caches, each one further from the visitor’s browser and each one slower but larger:

Edge cache (CDN): HTML, images and assets served from a POP near the shopper, often 20 to 60 ms away.
Server-side full page cache: the finished HTML stored by LiteSpeed, Nginx FastCGI or Varnish, served in 5 to 40 ms.
Object cache: Redis or Memcached holding query results, terms, options and transients in RAM.
Opcode and JIT cache: PHP OPcache keeping compiled bytecode so PHP 8.3+ never recompiles your theme on every hit.
Database cache: the InnoDB buffer pool inside MySQL or MariaDB, ideally big enough to hold your working set.

Each of these five layers has a different failure mode, which is why a single plugin toggle cannot do the job. Read the stack top to bottom and you can usually see exactly where your milliseconds are going.

Strategy 1: Public full-page cache with hole punching (ESI)

Edge Side Includes let the server cache one public copy of a product page while punching a hole for the mini-cart, the “welcome back” greeting or a customer-specific price block. The shell is served from cache, the hole is assembled per request, and PHP only builds the small fragment instead of the whole template.

On WooCommerce this is the single biggest win available, and it is one reason we build around LiteSpeed Cache rather than a generic file-based cache. In practice, ESI turns an uncacheable 1.4 s shop archive into a 40 ms response with a 30 ms fragment render behind it.

Strategy 2: Private cache for logged-in shoppers

Private caching stores a separate copy of a page per session, keyed on the session cookie, and it is the honest way to speed up account dashboards and B2B pricing. Keep TTLs short, generally 5 to 30 minutes, because the data behind them changes when the customer acts.

Two rules keep this safe. Never let a private response be stored by a shared cache (send Cache-Control: private, no-store at the edge), and always vary on the cookies that actually change output, not on every cookie your analytics stack sets.

Strategy 3: Redis object caching for repeated queries

A persistent object cache is where uncacheable pages get their speed back, since checkout still runs PHP on every request. Redis with the cache-aside (read-through) pattern typically removes 40 to 200 database queries per page load on a plugin-heavy store.

We cover this topic in more depth in How to Protect WordPress Against DDoS Attacks at the Server Level.

Watch three details when you deploy it:

Memory ceiling and eviction policy: use allkeys-lru with a hard maxmemory so Redis never swaps.
Key grouping: non-persistent groups like counts should stay out of the persistent store.
Flush discipline: a full flush during a sale sends a stampede of traffic straight into MySQL.

The Redis eviction documentation is worth ten minutes before you set those limits. Pair it with sane database tuning, which we covered in our guide to how your host should manage MySQL and MariaDB.

Strategy 4: Cache key hygiene

Every unnecessary variation in your cache key multiplies the number of objects you store and shreds your hit ratio. A store running four currencies, three customer groups and unfiltered UTM parameters can generate thousands of near-identical copies of one product page.

Strip or ignore tracking parameters (utm_*, fbclid, gclid) in the cache key.
Vary only on cookies that change rendered output: currency, language, customer group, logged-in state.
Normalise device buckets instead of caching per user agent string.
Give faceted filter URLs a separate, shorter TTL or exclude the deep combinations entirely.

A healthy store sits at a hit ratio above 85 percent on public pages. If you are under 60 percent, the problem is almost always the key, not the cache engine.

Strategy 5: Event-driven purges and stale-while-revalidate

Time-based expiry alone is a bad fit for commerce, because a price change needs to appear in seconds and a blog post can sit for a week. Hook purges to real events: order placed, stock level crossed, price updated, review approved, product saved. Then purge surgically, hitting the product URL, its parent category and the sitemap rather than the entire cache.

Layer stale-while-revalidate on top so the first visitor after expiry still gets an instant response while the server refreshes in the background. The behaviour and header syntax are documented well on web.dev, and it is one of the cheapest wins available for high-traffic category pages.

Finish with cache warming. A crawler that walks your top 500 URLs after a deploy or a nightly purge keeps real shoppers off cold pages, which matters most in the 20 minutes after you push an update.

Where the edge fits

Server-side and edge caching are complements, not rivals. The server decides what is cacheable and for how long; the edge decides how close to the shopper that decision gets executed. For a global store, moving cached HTML to a POP can cut 100 to 300 ms of round-trip latency on its own.

If you are weighing that trade-off, we go deeper in edge caching versus traditional CDNs and in our look at edge computing for dynamic WordPress content. Both assume the server-side layers above are already in place, since caching a slow origin at the edge just distributes the slowness.

What to measure once it’s live

Track four numbers weekly rather than chasing a single score. Cached TTFB (target under 200 ms), uncached TTFB for checkout (target under 600 ms), cache hit ratio, and PHP worker saturation during peak hours. When hit ratio drops and workers spike together, something in your key or purge logic changed.

Frequently Asked Questions

What is L1, L2, L3, and L4 cache?

In hardware, L1 through L4 are CPU cache levels, ranging from roughly 32 to 64 KB per core at L1 up to tens of megabytes of shared L3, each level slower and larger than the one above it. Web architects borrow the same idea: L1 is in-process memory, L2 is a shared store like Redis, L3 is the full page cache, and L4 is the origin database.

What is the best caching strategy?

For dynamic e-commerce, the best approach is layered: a public full-page cache with ESI hole punching, private cache for logged-in sessions, Redis object caching using cache-aside, and event-driven purges. No single pattern covers commerce, which is why single-layer setups either serve stale prices or barely improve speed.

Is Redis L1 or L2 cache?

Redis is an L2 cache in application terms, because it lives outside your PHP process and is shared across every server in the pool. An L1 cache would be the in-request memory array WordPress uses before it ever reaches Redis, typically served in microseconds versus Redis at 0.2 to 1 ms.

Is CDN a form of caching?

Yes, a CDN is distributed caching placed close to the visitor, usually across 30 or more edge locations. It stores copies of assets and, when configured for it, full HTML pages, though it still depends on the origin server sending correct cache headers.

Want caching that’s already configured for your store?

Our WordPress e-commerce hosting ships with LiteSpeed page caching, ESI, Redis object caching and purge rules mapped to WooCommerce events, so you are tuning TTLs rather than building a cache stack from scratch. Tell us your traffic pattern and current TTFB, and we’ll show you what the same store looks like on our platform.