WordPress caching can reduce work on the server. Each caching layer handles a different part of the process.
The best choice depends on the resource under pressure, the share of repeatable page views, and how much of the site must remain dynamic. A cache can improve loading speed without solving every CPU, RAM, database, disk, or bandwidth problem.
Table of Contents
What each caching layer does
| Caching layer | Work it can avoid | Best fit |
|---|---|---|
| Full-page caching | Repeated WordPress page generation for cacheable responses | Public pages that many visitors can receive in the same form |
| Object caching | Repeated retrieval or creation of data used while generating a page | Sites where WordPress repeatedly processes the same data |
| CDN caching | Repeated delivery of cached content from the origin server | Visitors requesting static or cacheable content from different locations |
LiteSpeed Cache for WordPress can work with server-level caching. On installations made automatically from the mybox panel, the plugin may already be available or ready for configuration. Its role is performance optimisation through caching at the WordPress and server levels, rather than a replacement for every other caching layer. Read the mybox overview of LiteSpeed Cache for WordPress.
How the layers affect server resources
CPU
Full-page caching can save the most page-generation work when visitors request the same public page. WordPress does not need to perform the full generation process for every cache hit. Object caching can also reduce repeated processing, but WordPress still has to handle the request and build the response around the cached data.
A CDN can reduce the number of requests that reach the origin server when the requested content is available in the CDN cache. This can lower origin-side processing for those requests. It does not remove CPU work for requests that must remain dynamic or are not served from the CDN cache.
RAM
Caching can change how server memory is used, but the effect depends on the cache layer and its configuration. Full-page caching avoids repeated application work, while object caching keeps reusable data available for later requests. A CDN keeps cached copies outside the origin server, so content served from the CDN does not need to be generated by mybox for every request.
High CPU and RAM use can lead to slow performance and 503 Service Unavailable errors. Caching is therefore relevant when repeated WordPress work contributes to resource pressure, but it should be assessed against the type of requests the site receives. See why a WordPress site can strain CPU and RAM.
Database queries
Object caching is the most direct choice when repeated data retrieval is part of the workload. It can reuse data while WordPress generates a response. Full-page caching can avoid database work altogether for a cache hit because the completed response is reused. A CDN normally does not reduce database queries for requests that still reach WordPress.
For a public site with many identical page views, full-page caching usually addresses repeated page-generation work more directly than object caching. For pages that must be generated for each request, object caching can be more relevant because it reduces repeated data work without requiring the entire response to be identical.
Disk I/O
Full-page caching and object caching can reduce repeated processing that may otherwise involve application or database activity. A CDN can reduce origin requests for content already held at the CDN edge. The exact effect on disk activity depends on how the cache stores and serves its data, so a faster page test alone does not prove that disk pressure has been removed.
Bandwidth
A CDN has the clearest role in reducing bandwidth served directly by the origin for content that is delivered from the CDN cache. Full-page caching can reduce the work needed to create a response, but the cached response may still be delivered by the origin. Object caching mainly targets internal data work and is not a direct way to move delivery away from the server.
Dynamic pages change the caching decision
Full-page caching works best when many visitors can receive the same public response. It needs more care for pages containing private, session-based, or user-specific content. WooCommerce is a clear example: the goal is to cache suitable content for guests while preserving private interactions for shoppers. See how caching is handled for WooCommerce on a CDN.
Object caching is useful alongside dynamic features because it does not require the complete page to be identical for every visitor. It can support repeated data work while the page remains personalised. A CDN can still serve suitable static or cacheable content, but private interactions should not be treated in the same way as public cacheable responses.
When combining caching layers helps
The layers can serve different purposes. Full-page caching can handle repeated public responses, object caching can reduce repeated data work for pages that still run through WordPress, and a CDN can deliver eligible cached content without sending every request to the origin.
Combining them becomes unnecessary when more than one layer tries to cache the same dynamic response. It can also make invalidation harder: a change may be reflected in one cache while an older copy remains in another. For a site with mostly public pages, start with the layer that matches the main bottleneck. For a dynamic site, preserve private interactions and use caching only where the response is safe to reuse.
Choosing the right layer for your traffic pattern
- Many visitors viewing the same public pages: prioritise full-page caching. Add a CDN when origin bandwidth or repeated delivery is the main concern.
- Many dynamic requests using the same WordPress data: consider object caching because the complete page cannot always be reused.
- Visitors distributed across locations: a CDN can reduce repeated delivery from the origin for content held in its cache.
- WooCommerce or other private interactions: keep guest-facing cacheable content separate from private shopper interactions. Do not treat every response as a public page.
- CPU and RAM pressure: identify whether the workload comes from repeated page generation or from dynamic processing. The appropriate cache layer depends on that distinction.
Key takeaway
Full-page caching is usually the strongest way to reduce repeated work for identical public pages. Object caching is better suited to repeated data work inside dynamic requests. A CDN mainly reduces origin delivery for content it can serve from its own cache. Use multiple layers only when each one has a separate role and dynamic, private responses remain protected.