TL;DR: Full-page caching is the highest-value optimisation for most WordPress sites and it does nothing for the pages that make a store money. Cart, checkout, my-account and admin are user-specific and must be excluded from page cache, so every one of those requests runs PHP and queries the database.
Object caching is what helps there. It keeps the results of database queries in memory, so repeated queries resolve without touching the database at all. On a content site the benefit is modest. On WooCommerce, where uncached pages are the commercial ones, it is frequently the single largest available improvement — and the two settings people get wrong, eviction policy and memory limit, are what turn it from a benefit into an intermittent bug.
Why page caching leaves a gap
Full-page caching stores the complete rendered HTML of a page and serves it to subsequent visitors without running PHP. For anonymous traffic on a blog or a product listing, this is enormously effective and it is why a well-cached site handles large traffic on modest hardware.
It cannot apply to pages that differ per user.
Pages that must be excluded from page cache on a store: cart, checkout, my-account, order confirmation, and anything showing user-specific state. Serving a cached cart to the wrong visitor is not a performance optimisation, it is a data leak.
What this means numerically. During normal browsing, most requests are cacheable and cheap. During a sale, the proportion of visitors sitting in cart and checkout rises sharply, and those are exactly the requests that consume PHP workers and database connections, as the festival sale guide covers.
So a store's performance under load is largely determined by how fast the uncacheable path runs, and page caching contributes nothing to it.
What consumes time on an uncached WooCommerce request: WordPress bootstrapping, loading active plugins, and then a substantial volume of database queries — options, product data, cart contents, shipping rules, tax rules, coupon validation, session data. A checkout page load can generate hundreds of queries.
Where object caching enters. Many of those queries are repeated, both within a single request and across requests. Options are read constantly. Product metadata is fetched repeatedly. Term relationships are queried again and again. Object caching keeps those results in memory so the database is consulted once rather than every time.
What object caching actually stores
Worth understanding, because it explains both the benefit and the failure modes.
WordPress has an internal object cache by default, and it is non-persistent. Query results are cached for the duration of a single page load and discarded when the request ends. The next request starts from nothing and repeats the same queries.
A persistent object cache backend, such as Redis, changes that. Results are stored in memory outside the PHP process, so they survive between requests and are shared across all visitors.
What gets cached:
Options, particularly the autoloaded set that is read on every request. Post and product objects. Post metadata, which for WooCommerce products is substantial. Term and taxonomy data. User data and capabilities. Transients, which are WordPress's own caching mechanism and which otherwise live in the database, adding write load.
Transients deserve a specific mention. Without a persistent object cache, transients are stored in the options table, so a mechanism intended to speed things up generates database writes and contributes to the table bloat discussed in the WordPress speed guide. With Redis configured, transients move to memory, which removes that write load entirely.
What does not get cached: the rendered page. Object caching is not page caching and does not replace it. You want both, doing different jobs.
The mental model: page cache avoids running PHP at all. Object cache makes PHP run faster when it must run. They are complementary, not alternatives, and a store needs both for different halves of its traffic.
Redis or Memcached
Both are in-memory key-value stores and both work as WordPress object cache backends. The differences are modest and mostly favour Redis for this use.
Redis supports data persistence to disk, richer data types, and a range of eviction policies. It is the more common choice in the WordPress ecosystem, which means better plugin support, more documentation and more community answers when something misbehaves.
Memcached is simpler, purely in-memory with no persistence, and very slightly leaner. It handles multi-threading differently, which matters at scales most WordPress sites never reach.
The practical position: use Redis unless your host only offers Memcached. The ecosystem support is the deciding factor rather than any performance difference, and being able to find an answer at 11pm when something is behaving oddly has real value.
Availability on shared hosting: many quality Indian shared hosts offer Redis, sometimes on higher tiers only. Ask specifically, since it is one of the more meaningful features to check when comparing plans for a store.
On a VPS, installing Redis is straightforward and it is one of the cheaper services to run, typically 50 to 300MB depending on your dataset, as covered in the Docker Compose sizing guide.
One architectural note: if you run multiple application servers, a shared Redis instance means they share a cache, which is correct. Running a separate Redis per server means divergent caches and inconsistent behaviour.
What to expect, honestly
Setting expectations properly, because the claims made for object caching vary from restrained to absurd.
On a content site with good page caching: modest benefit. Most traffic is served from page cache and never reaches PHP, so the object cache helps only logged-in users and admin. Worth having, not transformative.
On WooCommerce: substantially more, because the commercially important pages cannot be page-cached. Reductions in database query counts on cart and checkout pages are typically large, since so many repeated queries resolve from memory instead.
In the admin area: frequently the most noticeable improvement to the people who work on the site daily. The dashboard, product editing and order screens are all uncacheable and query-heavy.
What determines how much you gain:
How many plugins you run, since each adds queries. Sites with many plugins gain more.
How large your product catalogue and order history are, since query cost grows with table size.
Whether your database is already a bottleneck. If your uncached page load is slow because of PHP execution rather than database queries, object caching helps less.
How much autoloaded option data you carry. A bloated options table benefits enormously.
What it will not do: fix a slow site whose problem is oversized images, a distant server, or unoptimised front-end code. Object caching is a server-side database optimisation and nothing else. If your time to first byte is fine and the site still feels slow, this is not your fix.
The honest summary: for a WooCommerce store with real order volume, this is one of the highest-value changes available. For a five-page brochure site, skip it.
Installing and connecting it
The sequence, at a level that survives different hosting arrangements.
On shared hosting with Redis available: the host typically provides a socket path or host and port, sometimes with a password. Enable Redis in your control panel, note the connection details, then install a WordPress object cache plugin and point it at those details.
On a VPS: install Redis from your distribution's packages, or run it as a container. Then install the PHP Redis extension, which is the step people forget — the plugin needs a PHP extension to talk to Redis, and without it the connection silently fails.
Bind Redis to localhost. Redis has historically been a target precisely because instances get exposed to the internet with no authentication. It should listen on the loopback interface or a Unix socket only, never on a public interface. If you are running it in Docker, publish nothing, since containers reach each other on the internal network, and check what is actually listening rather than trusting your firewall.
Set a password even on localhost, as defence in depth.
Install the object cache plugin and enable it. The plugin drops a persistent object cache file into wp-content and WordPress begins using Redis as its backend.
Set a unique key prefix if multiple sites share one Redis instance. Without it, two WordPress installations will overwrite each other's cache entries, producing symptoms that look like data corruption and are extremely confusing to diagnose.
Then verify, using the checks further down, rather than assuming the connection worked.
The settings that go wrong
Three configuration items cause nearly all Redis problems on WordPress, and defaults are frequently wrong.
Maximum memory. Redis with no memory limit grows until it consumes what is available, and on a small server that ends with the out-of-memory killer terminating something important, usually your database. Set an explicit maxmemory value sized to your allocation with headroom.
Eviction policy. This is the one that produces the strangest bugs. Redis's default policy in some configurations is to return errors when memory is full rather than evicting anything. For a cache, that is wrong: you want old entries discarded to make room for new ones.
Set an eviction policy that discards least-recently-used keys. With the wrong policy, a full Redis starts refusing writes, and WordPress behaves erratically in ways that do not obviously point at the cache.
Persistence. Redis can write its dataset to disk so it survives a restart. For an object cache, persistence is usually unnecessary, since a cold cache simply repopulates from the database. Disabling it removes disk I/O and avoids the periodic pauses that snapshotting can cause.
The exception is if you also use Redis for something that genuinely needs durability, in which case use a separate instance or database index rather than compromising both.
A fourth item worth checking: the key prefix, mentioned above, which matters the moment more than one site shares an instance.
| Setting | Common wrong value | What to use | Symptom if wrong |
|---|---|---|---|
maxmemory |
Unset | Explicit limit with headroom | OOM killer terminates database |
| Eviction policy | Errors when full | Evict least-recently-used keys | Erratic behaviour, refused writes |
| Persistence | Enabled by default | Usually disabled for cache use | Disk I/O, periodic pauses |
| Bind address | All interfaces | Localhost or Unix socket | Internet-exposed Redis |
| Password | Unset | Set, even on localhost | Weak defence in depth |
| Key prefix | Unset | Unique per site | Sites overwrite each other's cache |
| PHP Redis extension | Not installed | Installed and enabled | Plugin silently fails to connect |
| Object cache plugin | Not enabled after install | Enabled, drop-in present | No caching despite Redis running |
Verifying it is actually working
The step that separates a configured object cache from a decorative one.
Check the plugin status. Most object cache plugins report connection status, and it should show as connected with a valid backend. This is necessary and not sufficient, since a connected cache can still be misconfigured.
Check the hit ratio. A healthy object cache shows a high proportion of hits to misses after the site has been running for a while. A low ratio suggests entries are being evicted too aggressively, usually because maxmemory is too small for your workload.
Compare query counts. Use a query monitoring plugin on a staging site to record the number of database queries on a cart or checkout page load, then enable object caching and measure again. The reduction is the actual benefit, expressed in the only terms that matter.
Do this on staging rather than production, as the staging guide recommends, since a query monitor on a live store adds its own overhead.
Measure time to first byte on an uncached page. Checkout, not the homepage. This is the number that reflects the commercial benefit.
Check Redis memory use against your configured limit. Sitting at the ceiling constantly means you are evicting more than you should and would benefit from more memory.
Test after a Redis restart. The site should continue working with a cold cache, simply slower, and repopulate. If it errors, something is wrong with your failure handling.
Re-verify after plugin updates. Object cache drop-ins occasionally get overwritten by other plugins or by updates, silently disabling caching. A quarterly check is worth the two minutes.
When object caching is not the answer
Cases where it will disappoint, and where your effort belongs elsewhere.
Your site is slow because of front-end weight. Oversized images, render-blocking scripts, a heavy page builder. Object caching improves server response time and does nothing for what happens in the browser. Check time to first byte first: if it is already good, this is not your problem.
Your server is far from your audience. Distance is not optimisable by any caching layer. An India-focused site on overseas hosting should move region before tuning anything.
Page caching is not working. Fix that first, since it removes far more load than object caching adds benefit. Verify it with response headers rather than trusting the plugin dashboard.
Your database is bloated with autoloaded options. Object caching will mask this by keeping the bloat in memory, which helps and leaves the underlying problem in place. Clean the options table as well.
You have one plugin running an expensive unindexed query. Object caching helps if the query result is reused and not if it is unique per request. Find and fix the query.
Your site is a small brochure site. The benefit is negligible and you have added a service to maintain.
You cannot manage another moving part. Redis is one more thing to monitor, patch and size. On a VPS you administer, that is a real if small cost. If nobody is watching your server, adding services is not the priority.
FAQs
What is object caching in WordPress?
Object caching stores the results of database queries in memory so repeated queries do not hit the database. WordPress has a built-in object cache that lasts only for a single page load; a persistent backend such as Redis makes those results survive between requests and be shared across all visitors, which is where the benefit comes from.
Is object caching the same as page caching?
No, and you want both. Page caching stores the fully rendered HTML and avoids running PHP at all, which works for anonymous visitors on cacheable pages. Object caching makes PHP run faster when it must run, which is what helps on cart, checkout, account and admin pages that cannot be page-cached.
Does Redis help WooCommerce?
Substantially, more than on a content site, because the commercially important pages are exactly the ones page caching cannot serve. Cart and checkout run PHP and generate large numbers of database queries on every load, and object caching resolves the repeated ones from memory instead.
Should I use Redis or Memcached?
Redis, unless your host only offers Memcached. The performance difference for WordPress is small; the deciding factor is ecosystem support, since Redis has better plugin integration, more documentation and more community answers, which matters when you are diagnosing odd behaviour.
Why is my Redis object cache not working?
Most commonly the PHP Redis extension is not installed, so the plugin cannot connect despite Redis running. Other frequent causes are the object cache drop-in not being enabled, wrong connection details, a missing password, or another plugin having overwritten the drop-in file during an update.
What eviction policy should Redis use for WordPress?
One that discards least-recently-used keys when memory is full. Some default configurations return errors instead of evicting, which for a cache is wrong and produces erratic WordPress behaviour that does not obviously point at Redis. Set the policy explicitly rather than relying on the default.
Do I need to set a memory limit on Redis?
Yes. Without an explicit maxmemory value, Redis grows until it consumes available memory, and on a small server that ends with the out-of-memory killer terminating another process, frequently your database. Set a limit sized to your allocation with headroom, and monitor whether you sit at the ceiling.
Should Redis persistence be enabled?
Usually not for object cache use. A cache does not need durability, since a cold cache simply repopulates from the database, and disabling persistence removes disk I/O and avoids the periodic pauses snapshotting can cause. If you need Redis for something durable as well, use a separate instance.
How do I know if object caching is actually helping?
Compare database query counts on a cart or checkout page before and after, using a query monitoring plugin on staging. Then measure time to first byte on an uncached page such as checkout. Also check the cache hit ratio, since a low ratio suggests entries are being evicted too aggressively for your memory allocation.
Can multiple WordPress sites share one Redis instance?
Yes, provided each site uses a unique key prefix or a separate database index. Without that, sites overwrite each other's cache entries, producing symptoms that resemble data corruption and are very confusing to diagnose. Set the prefix at setup rather than discovering the problem later.
Is Redis safe to expose on my server?
Only bound to localhost or a Unix socket, never a public interface, and with a password set even locally. Exposed Redis instances are a well-known target precisely because they are frequently deployed with no authentication. If running in Docker, publish no ports and verify what is actually listening rather than trusting firewall rules.
Will object caching fix my slow site?
Only if the constraint is repeated database queries on uncached pages. If time to first byte on a cached page is already good, or your server is far from your audience, or your pages carry several megabytes of images, object caching is not your fix. Diagnose before installing.
Conclusion
Object caching solves a problem most WordPress performance advice ignores, because most advice is written for content sites where page caching handles nearly everything.
Stores are different. The pages that make money are the pages that cannot be cached, and their speed is determined by how quickly PHP and the database can answer. That is exactly the gap object caching fills, which is why it belongs near the top of a WooCommerce optimisation list and near the bottom of a brochure site's.
Get the three settings right and it is close to maintenance-free. An explicit memory limit so it cannot starve your database. An eviction policy that discards old keys rather than refusing writes, because the wrong policy here produces bugs that look like anything except a cache problem. And persistence off, since a cache does not need durability.
Then verify with numbers rather than a status indicator. Query counts on a checkout page before and after, measured on staging, tells you what you actually gained. A green connection light tells you almost nothing.
And keep the order of operations straight. Page caching first, verified in response headers. Server in the right region. Autoloaded options cleaned. Then object caching, which makes the remaining uncacheable traffic considerably cheaper.
HostCloud offers Redis object caching alongside LiteSpeed server-level page caching and NVMe storage on Indian infrastructure, which covers both halves of a store's traffic. Plans from ₹99 a month at https://www.hostcloud.in.