How Caching Works On Oxyforge
Caching is the reason a WordPress page can be delivered in a few milliseconds instead of a few hundred. It works by keeping the answer to a request that has already been worked out, so the next visitor gets the saved copy rather than making the server do the work again.
On Oxyforge this is already running on every website. There is nothing to install, nothing to configure and nothing to buy.
The Three Layers
Three separate caches sit between a visitor and your database, and each one catches a different kind of work.
The full-page cache lives in Nginx, the web server in front of WordPress. When a visitor asks for a page, Nginx stores the finished HTML. The next person who asks for that page gets the stored copy, and PHP is never woken up at all. This is the layer that does the most for an ordinary brochure or blog page.
The object cache uses Redis, which keeps data in memory. WordPress asks the database the same expensive questions over and over, such as working out a menu, resolving a set of options or counting products in a category. Redis remembers the answers so the database is asked once instead of once per visit. This matters most on WooCommerce, on membership sites and on a busy WordPress dashboard, because those pages cannot be served from the page cache.
Cloudflare sits in front of everything. By its own default behaviour it serves your static files, meaning images, stylesheets, scripts and fonts, from its own network at a location close to the visitor. A shopper in London gets those files from London rather than from Singapore. This is also why your bandwidth usage is usually lower than a raw traffic estimate suggests. See bandwidth explained.
| Layer | What it stores | Who it helps most |
|---|---|---|
| Nginx page cache | Finished HTML of a page | Logged-out visitors on any site |
| Redis object cache | Results of database lookups | Shops, dashboards, logged-in users |
| Cloudflare | Images, CSS, JavaScript, fonts | Visitors far from Singapore |
Do Not Install A Caching Plugin
Remove WP Rocket, W3 Total Cache, LiteSpeed Cache and anything else that advertises page caching. They duplicate work the platform already does, and they frequently cause the problems people then blame on the host: stale pages, broken carts, a minified stylesheet that fights with the one Cloudflare has, and a cache the platform cannot clear for you.
If you are moving a site here, uninstalling the caching plugin is one of the first things to do after the copy lands. Deactivating is not quite enough, because some of these plugins leave behind a drop-in file or rewritten rules that still interfere. Delete the plugin properly.
Image optimisation plugins, security plugins and SEO plugins are fine. It is specifically page caching, object caching and asset minification that overlap with the platform.
What Clears Itself
The cache is not something you are meant to think about day to day, because the common actions clear it for you.
- Publishing or updating a post or page clears the whole site’s page cache, usually within about twenty seconds. Pages rebuild on their first visit, so the home page and the archives the post appears in are fresh the next time anyone opens them.
- Changing your permalink structure does the same, because every stored URL has moved.
You should be able to publish, look at the live site, and see your change.
What Is Never Cached
The page cache is only used for anonymous visitors looking at ordinary pages. It is bypassed entirely when:
- The visitor is logged in to WordPress, or has left a comment on the site.
- There is something in the cart, or the visitor is in checkout.
- The request is for the WordPress dashboard, an admin page, the REST API,
wp-cron.php,xmlrpc.phpor the comment form. - The address carries a query string that is not a known tracking parameter, which covers on-site search and anything sorted or filtered through the URL.
- The request is a feed, a sitemap or a
.txtfile, or a password-protected post. - The request is anything other than a plain page load, such as a form submission.
Staging copies are never page cached at all, so a staging site always shows you the live result of a change.
This is why a shop works normally here. A customer adding a product to their basket is served fresh pages from that point on, so they never see someone else’s cart or a stale price. The object cache keeps those uncached pages fast, which is the division of labour between the two layers.
When You Need To Clear It By Hand
Automatic clearing covers changes made inside WordPress. It cannot know about changes made outside WordPress, so if you edit a template file over SFTP, or change something directly in the database, the stored page may still show the old version.
For that, the site’s Tools tab has a Clear Cache button. See clear the cache for when to use it and what to try next if the change still has not appeared.
Caching Is Not A Fix For A Slow Page
A cache makes repeat delivery fast. It does not make your page lighter. If a page carries four megabytes of unoptimised photographs, or a page builder loading twelve stylesheets, the cached version still carries all of that to the visitor. The server answers quickly and the page still feels slow.
That distinction is worth understanding before you start optimising, and why a WordPress site feels slow walks through how to tell the two apart.
Did this answer it? If not, open a ticket from the members area and someone who runs the platform will pick it up.
Open A Ticket