WordPress Caching: Modern Guide to Full Page Caching
Full page caching is the fastest way to serve WordPress content. Learn how LiteSpeed, Redis, and CDN integration work together to eliminate database queries and cut load times by 70%—critical for SA sites managing load shedding and peak traffic.
Key Takeaways
- Full page caching bypasses PHP and database queries entirely, serving pre-rendered HTML to visitors—reducing load times by 60–80% on most WordPress sites.
- LiteSpeed Cache, Redis object caching, and Cloudflare CDN work together as a three-layer stack; implement all three for maximum speed and resilience during SA load shedding events.
- Cache invalidation (clearing stale content) is critical: set smart TTLs, use event-based purging for posts/products, and monitor cache hit ratios to ensure visitors always see fresh content.
Full page caching is the single most effective performance optimization for WordPress. Instead of running PHP code and database queries on every visitor request, caching serves a pre-rendered HTML file from server memory or edge locations. For South African sites, this is non-negotiable: full page caching can reduce response times from 500ms to 100ms, meaning your site stays fast even during load shedding when network congestion peaks. This guide covers exactly how to implement full page caching in 2025, what to avoid, and how to measure success.
At HostWP, we've migrated over 500 WordPress sites across South Africa in the past 18 months. A consistent finding: 73% of those sites had zero caching strategy. After implementing LiteSpeed Cache (which comes standard on all our plans) and Redis integration, the average load time fell from 2.8 seconds to 0.9 seconds. That's a 68% improvement. For e-commerce sites like WooCommerce stores in Cape Town and Johannesburg, that drop translates directly to conversion rate increases of 15–25%.
In This Article
How Full Page Caching Works
Full page caching generates a static HTML snapshot of your WordPress page and serves it directly to visitors, bypassing the WordPress engine entirely. When a visitor lands on your site, the web server checks: is there a fresh cached version? If yes, send it immediately. If no, WordPress loads, queries the database, renders the page, and caches the result for the next visitor. This is why full page caching is so powerful—it trades computation time for storage space, and storage is cheap.
The process has three stages: cache generation (when a page is first visited or after cache clears), cache serving (hitting the cached HTML instead of WordPress), and cache invalidation (clearing old versions when content changes). For WordPress, this usually happens at the web server level (LiteSpeed), object cache layer (Redis), and edge network level (CDN like Cloudflare). Without proper invalidation, visitors see outdated content—product prices from last week, blog posts that were unpublished, customer comments stuck in limbo.
Zahid, Senior WordPress Engineer at HostWP: "I've audited over 200 WordPress sites in South Africa, and the sites with the fastest response times all use the same pattern: LiteSpeed full page cache hit rate of 85%+, Redis for object caching, and Cloudflare for edge caching. Sites without this stack typically have cache hit rates below 40%, meaning the majority of traffic still runs through PHP. That's why we made LiteSpeed + Redis standard on all HostWP plans—it's the difference between a site that feels fast and one that doesn't."
LiteSpeed Cache: Setup and Configuration
LiteSpeed Cache is a server-level caching plugin specifically built for the LiteSpeed web server (which powers all HostWP managed WordPress hosting). It's different from generic caching plugins like WP Super Cache because it integrates directly with the server—no PHP overhead, no database load. LiteSpeed Cache runs as a module, generating and serving cached pages instantly.
To set up LiteSpeed Cache correctly, install the LiteSpeed Cache WordPress plugin from the repository. Go to Settings → LiteSpeed Cache and enable these core features: Enable Caching, Enable HTTP/2 Push, and Cache Browser TTL (set to 3600 seconds for static assets). Set Public Cache TTL to 86,400 seconds (24 hours) for standard content; for news sites or high-traffic blogs, use 3,600 seconds (1 hour). For WooCommerce sites, enable Purge on checkout and cart update to ensure pricing and inventory are always current.
Critical: under Advanced → Optimization, enable CSS Minification, JavaScript Minification, and Image Lazy Loading. These features reduce page weight by 30–40% on average. Image lazy loading is especially important for load shedding scenarios—if a visitor's connection drops mid-page-load in Johannesburg, lazy loading ensures critical above-the-fold content loads first. Set Exclude URIs to skip caching on your cart, checkout, account pages, and any dynamic content (like real-time quote widgets or live chat pages).
HostWP includes LiteSpeed Cache, Redis, and Cloudflare CDN on all plans. If you're on shared hosting elsewhere and want this stack, consider a free migration—we'll move your site, configure caching, and test performance before going live.
Get a free WordPress audit →Redis Object Caching: The Second Layer
While LiteSpeed full page caching handles entire pages, Redis handles object caching—the temporary storage of database queries, transient data, and API responses. Redis is an in-memory data store that's dramatically faster than MySQL: typical Redis response times are 1ms versus 50–200ms for database queries. For sites with heavy plugins (SEO, bookings, complex WooCommerce filters), Redis can cut backend load by 60%.
To enable Redis on HostWP, use the Redis Object Cache plugin (by Till Krüss, maintained by Daniel Roch). Install it, and if your hosting provides Redis (we do on all plans from R399/month), it auto-detects and connects. You'll see a green "Connected to Redis" message in the Settings → Redis Object Cache dashboard. Redis then caches: WordPress transients (temporary data from plugins), database query results, WooCommerce product metadata, and API responses.
Monitor Redis via Settings → Redis Object Cache → Diagnostics. You want to see a Cache Hit Ratio above 70%—that means 70% of object requests are served from Redis memory instead of the database. If it's below 40%, you likely have plugins making non-cacheable database queries on every page load. For WooCommerce sites, Redis is essential: product filters, cart calculations, and inventory checks all hit Redis instead of MySQL, keeping checkout fast even during peak traffic (or during load shedding when customers panic-buy).
CDN Integration with Cloudflare
A CDN (Content Delivery Network) caches your content on servers distributed globally. Cloudflare's free and Pro plans cache static assets (CSS, JavaScript, images) and can cache dynamic content (HTML pages) with proper cache headers. For South African sites, Cloudflare routes traffic through nearby edge locations (Cape Town, Johannesburg), reducing latency for local visitors and protecting against DDoS attacks—important given South Africa's internet infrastructure challenges during peak hours.
To integrate Cloudflare: sign up (free tier available), point your domain's nameservers to Cloudflare, and install the CloudflareCaching Level to "Cache Everything" and Browser Cache TTL to 1 month for CSS/JS/images. For pages, use Page Rules to cache HTML with a 1-hour TTL.
Crucially, add Cloudflare's IP ranges to your WordPress whitelist (in LiteSpeed Cache → Settings → Advanced → IPs Whitelist). This prevents rate-limiting conflicts. Also, under Cloudflare's Speed settings, enable Rocket Loader (JavaScript optimization) and Mirage (image optimization for slow connections)—Mirage is particularly useful for South Africa, where mobile users on 3G networks benefit from adaptive image loading. For POPIA compliance (South Africa's privacy law), verify that Cloudflare's data handling meets local standards; Cloudflare complies, but document it in your privacy policy.
Smart Cache Invalidation Strategies
Cache invalidation is "one of the two hard things in computer science" (along with naming). Clear cache too frequently and you lose performance; too infrequently and visitors see stale content. The solution is event-based purging: clear specific caches only when content actually changes.
In LiteSpeed Cache, set up automatic purging: when you publish a post, LiteSpeed automatically clears the full page cache for that post and its related archives (homepage, category pages, search results). For WooCommerce, enable "Purge on product update" so changing inventory or price immediately clears relevant product and shop page caches. Use manual purges sparingly—only for emergency corrections.
For Redis, most transients have built-in expiration (you set TTL when creating them), so manual clearing is rare. However, problematic plugins might create permanent transients—check Settings → Redis Object Cache → Diagnostics → Transients to spot these and disable the plugin or ask the developer for a fix. For Cloudflare, use the Cloudflare WordPress plugin's "Purge Everything" only after major updates; for routine posts, purge just that page's URL.
A smart strategy for South African news or deal sites: set LiteSpeed Cache TTL to 1 hour during business hours (8 AM–6 PM ZAR), then 4 hours overnight. During load shedding events (which are predictable via EskomSePush API), temporarily reduce TTL to 30 minutes to ensure urgent updates (like "Stage 6 load shedding" notices) propagate quickly. This balances freshness and performance under network stress.
Monitoring and Measuring Cache Performance
Measure cache effectiveness with three metrics: cache hit ratio, page load time, and Time to First Byte (TTFB). In LiteSpeed Cache settings, enable debug logging (Settings → Advanced → Debug Log). You'll see X-LiteSpeed-Cache headers in HTTP responses: "hit" means the cached version was served, "miss" means it wasn't, "stale" means the cache expired. Aim for 85%+ hit rate on static pages.
Use Google PageSpeed Insights (pagespeed.web.dev) to measure real-world performance. Your site should show First Contentful Paint (FCP) under 1.5 seconds and Largest Contentful Paint (LCP) under 2.5 seconds on mobile. If LCP is slow despite high cache hit rates, the bottleneck is likely image size or render-blocking JavaScript—optimize images further or defer non-critical scripts.
Monitor via your hosting dashboard. HostWP customers can see cache hit ratios in cPanel → Metrics and real-time page load times via our performance monitoring. Set up alerts: if average TTFB exceeds 200ms, investigate why (might be a plugin making non-cacheable database calls, or Redis connection issues). For WooCommerce, monitor add-to-cart speed and checkout completion time—these are sensitive to cache misses and Redis lag.
Document your baseline before implementing caching, then measure again after 1 week. At HostWP, we've seen average improvements of 60–70% in load time and 40–50% reduction in server CPU usage. These translate to lower bandwidth costs (if you're not on managed hosting) and better Google rankings (Core Web Vitals impact SEO).
Frequently Asked Questions
Q: Will full page caching break my site's dynamic content like WooCommerce checkout?
No, if configured correctly. Exclude checkout, cart, my-account, and any admin pages from caching via LiteSpeed Cache → Settings → Exclude URIs. These pages run without caching and remain fully dynamic. Use cache-control headers or WordPress functions to prevent caching on specific pages (e.g., add_filter('litespeed_cacheable', '__return_false') in a custom plugin). WooCommerce sites cache the shop and product pages, not the cart flow.
Q: What's the difference between LiteSpeed Cache and WP Super Cache?
LiteSpeed Cache runs at the server level (in the LiteSpeed web server module), so it's faster and uses less PHP overhead. WP Super Cache is a plugin-level cache that still requires some PHP execution. If your server uses Apache or Nginx (not LiteSpeed), you'll need WP Super Cache or similar. On HostWP, we use LiteSpeed exclusively, so LiteSpeed Cache is always the best choice—it's also free and included.
Q: How do I cache dynamic content like personalized product recommendations?
Use object caching (Redis) instead of full page caching. Create separate cache keys for each user segment (e.g., 'recommendations_user_' . $user_id). Load recommendations from Redis/database once, then serve them via AJAX after the page loads. This gives you the speed of caching plus personalization. Use plugins like WooCommerce Product Recommendations or custom code with Redis transients.
Q: Does Cloudflare's free plan cache my WordPress pages?
By default, Cloudflare caches only static assets (CSS, JS, images) on the free plan. To cache HTML pages, you must add a Page Rule (free plans get 3 rules) or use the Cloudflare WordPress plugin to set proper cache headers. Paid Cloudflare plans (starting $20/month) offer more rules and advanced features like Workers for conditional caching. Most South African small businesses are fine with free + LiteSpeed Cache.
Q: What should I do during Eskom load shedding to keep my site fast?
Load shedding doesn't directly affect your site's speed if it's on managed hosting with redundant power (HostWP has generator and UPS backup in our Johannesburg data centre). However, your visitors' connections may be spotty. To prepare: reduce cache TTL to 30 minutes (so urgent updates like "load shedding stage increased" propagate fast), enable image lazy loading, and minimize JavaScript. Test your site on slow connections (throttle to 3G in Chrome DevTools) to confirm it's usable even if a visitor's network drops.
Sources
- Google Web Performance Best Practices
- Web.dev Performance Guidance
- LiteSpeed Cache WordPress Plugin Repository
Full page caching isn't optional anymore—it's the baseline expectation for fast WordPress sites. Implement the three-layer stack (LiteSpeed full page cache, Redis object cache, Cloudflare CDN) and you'll outpace 95% of competing sites. Start today: if you're already on HostWP, verify LiteSpeed Cache is active in your dashboard and Redis is connected (check Settings → Redis Object Cache). If you're not, test your current load time at pagespeed.web.dev, then contact our team for a free audit to see how much faster you could be.