Users never see these two optimizations, but they solve two rather classic structural problems in WordPress.
The 30-second version
| Item | Detail |
|---|---|
| What an object cache does | Remembers the results of repeated database queries |
| Who notices most | Admin work and store sites |
| How it differs from full-page cache | Full-page cache cannot help uncacheable pages; an object cache can |
| The wp-cron problem | By default it rides on visitor traffic, so no visitors means nothing runs |
| Do you configure it | No |
Problem 1: wp-cron rides on page requests
WordPress’s built-in scheduler, wp-cron, is not really cron by default. It hangs off page requests — WordPress checks whether any scheduled jobs are due only when someone happens to be browsing your site.
That causes two problems:
- On a site with no traffic, schedules never run. Your scheduled posts, backup plugins and data syncs all stall through the small hours when nobody visits.
- On a site with traffic, a visitor waits for you. Whichever unlucky visitor triggers the schedule has the job’s execution time added to their page load.
RoamerHost disables page-request triggering and instead has the platform scheduler actively fire wp-cron for every running site every 5 minutes, 10 sites in parallel. Schedules run on time, and the cost of running them is never passed on to a visitor’s load time.
Problem 2: the object cache
Every time WordPress builds a page it makes a lot of database queries — options, post meta, taxonomies, user data. Without an object cache, those queries run again on every single request.
RoamerHost gives every site a Redis object cache with per-site ACL isolation: each site has its own Redis user and password and can only touch its own keys.
Why does ACL isolation matter? Because the classic disaster with a shared Redis is one site running FLUSHDB and wiping the cache for every site at once. That is in fact exactly what WP-CLI’s wp redis enable command does — it calls flushdb. RoamerHost deliberately avoids that command when enabling the cache and writes the configuration another way, precisely so no single site has the ability to affect the others.
What this actually means for you
If you are migrating from another host, you may notice:
- Admin work feels smoother (the cache absorbs a pile of queries)
- Scheduled posts genuinely publish on time (no more waiting for a visitor)
- You do not need to install a separate object cache plugin, or stand up your own Redis
One thing to be clear about: an object cache speeds up database queries, not page rendering as a whole. If what you want is full static page caching, that is a different layer, and you can pair it with the LiteSpeed Cache plugin — OpenLiteSpeed supports it natively.
Why the admin side feels it most
The public side of a site can lean on full-page caching: the page is generated once and everyone afterwards gets the same ready-made HTML.
But the admin cannot be cached. Every time you load the post list, open the editor or browse the media library, the database is queried live. And a single WordPress admin page load can trigger dozens or even hundreds of queries, many of them duplicates.
An object cache remembers the duplicates, which is why its effect is most visible in the admin. It is also why “the site is fine but the admin is slow” is the textbook case for an object cache.
Why wp-cron had to change
By default, WordPress scheduled tasks are “check whether anything is due whenever a visitor shows up”. That design has two problems:
- No visitors, no execution. A scheduled post or backup in the middle of the night may not run at all.
- Visitors mean constant checking. Under heavy traffic, every request does one more thing.
Moving the trigger to a system-level scheduler solves both at once — when the time comes it runs, regardless of visitors, and without taking up a visitor’s request.
If you have ever had a scheduled post fail to go out on time, this is the reason nine times out of ten.
When you will not notice a difference
Honestly, there are sites where installing an object cache changes very little:
- Purely static content with few posts — there were never many queries to save
- Full-page caching already absorbs 90% of requests — visitors never reach the database
- You only browse the public site and rarely open the admin — you skip the part that benefits most
The sites that clearly feel it are the other kind: lots of plugins, lots of products, frequent admin work, or dynamic pages that cannot be cached. Store sites almost always fall into this group.
FAQ
Q: Do I need to install a plugin myself?
No, the environment is already configured. This article explains what it does and why you can feel it.
Q: What is the difference between an object cache and a full-page cache?
A full-page cache stores “the finished page”; an object cache stores “the intermediate results used to build the page”. The former does nothing at all for pages that cannot be cached; the latter still helps. A store’s checkout page is the textbook example.
Q: If data changes, will I see a stale version?
No. When data changes the matching cache entry is invalidated and the next query fetches it fresh.
Q: Why are my scheduled posts still late?
First check the time zone setting for the publish time, then check the post’s schedule status. Moving to a system scheduler cuts these problems down a lot, but a wrong time zone is not something a scheduler can fix.
Q: How much faster will my site be?
There is no universal number. The biggest variable is how many repeated queries your site makes — sites with many plugins, many products and complex queries benefit most; a ten-post blog will barely notice.
What managed hosting saves you
Self-hosted, the whole set is yours to do: install Redis, configure the connection, install the matching plugin, confirm it is actually working, handle version upgrades, watch memory usage.
The most underestimated part is “confirm it is actually working” — installing the plugin does not mean the cache is running, a misconfiguration is completely invisible on screen, and the site keeps working, just no faster. You have to look at the hit rate to know.
A managed environment sets all of this up and keeps it maintained, which is part of the hidden cost described in the cost breakdown: not the hour spent installing it, but the time spent on every upgrade and investigation afterwards.
Sources and further reading
Object cache behavior is defined by the official Redis and WordPress documentation:
- Redis official documentation
- WordPress developer documentation — caching and APIs
Further reading
- When to upgrade your WordPress plan: Basic vs Pro
- Hosting requirements for a WooCommerce store: why ordinary WordPress hosting falls short
- Why OpenLiteSpeed: picking an engine for WordPress hosting
- WordPress for beginners
Want someone to build it for you?
When requirements go beyond what plugins can do, someone has to touch the code. Roamer Tech takes on advanced WordPress development:
