Series: WordPress Performance on DirectAdmin (Rocky Linux 9)

Phase 6: Caching & CDN Strategy — Part 24 of 30

How to Avoid Double Caching WordPress (And When It Happens)

WordPress performance tuning on DirectAdmin with Rocky Linux 9 often involves deploying one or more caching layers: web server (Nginx/Apache), PHP opcode cache, and application-level plugins. However, double caching—when two or more caches are layered without awareness—can cause stale content, debugging headaches, and wasted resources. This article details where double caching occurs, how to detect it, and how to prevent it in DirectAdmin-managed environments.

Key Concepts: Caching Layers in DirectAdmin WordPress Stacks

• Web Server Caching: Nginx/Apache may be configured for static or proxy caching. DirectAdmin’s custom templates often control these behaviors per domain.
• PHP Opcode Cache: Opcache accelerates PHP execution but does not cache HTTP responses.
• WordPress Plugin/Object Cache: Plugins like WP Super Cache, W3 Total Cache, or persistent object caches (Redis/Memcached) store generated pages or DB queries.
• CDN/Reverse Proxy: External edge caches (Cloudflare, etc.) can add another layer.

Where Double Caching Occurs

• Both web server and WordPress plugin cache full pages.
• Multiple WordPress plugins with overlapping page/object cache roles.
• External CDN/proxy caching combined with internal caches (without proper coordination).

Symptoms of Double Caching

• Stale content persists after clearing one cache layer.
• Cache-control headers conflict or are missing (check with curl -I).
• Frequent user complaints about not seeing updates, especially after publishing or plugin/theme changes.
• High memory/disk usage in cache directories.

DirectAdmin-Specific Caching Scenarios

1. Nginx Reverse Proxy + WordPress Full-Page Cache

DirectAdmin’s Nginx-as-reverse-proxy setup (default on many Rocky Linux 9 installs) can cache static assets and, if configured, also full HTML responses. If a WordPress plugin (e.g., WP Super Cache) is also caching pages, cache invalidation can break—especially if Nginx’s cache isn’t purged after WP cache events.

2. Apache mod_cache + WordPress Cache Plugin

If Apache templates are modified to enable mod_cache, ensure it doesn’t overlap with plugin-based page caching. Apache’s cache may serve stale content after a WordPress cache purge.

3. Redis/Memcached + Plugin Page Cache

Object caches (Redis/Memcached) are safe to combine with full-page caching, but using multiple plugins for each can cause unexpected results. Avoid stacking more than one object cache or page cache solution unless you have a clear, tested reason.

4. CDN Caching with Web Server or Plugin Cache

CDNs (like Cloudflare) cache at the edge. If you’re also using Nginx/Apache cache or a WordPress plugin cache, purging one cache layer does not affect the others unless explicitly integrated.

How to Detect Double Caching

Checklist: Diagnosing Overlapping Caches

1. Check headers from your origin:

   curl -I -H "Host: yourdomain.com" http://127.0.0.1/

   • Look for X-Cache, Cache-Control, X-Proxy-Cache, or plugin-specific headers.
2. Test cache purges:
   • Clear the WordPress plugin cache, reload the page, and check if content updates.
   • Purge web server cache (see below), then retest.
3. Inspect logs for cache hits/misses:

   sudo tail -f /var/log/nginx/access_log
   sudo tail -f /var/log/httpd/access_log

Testing with WP-CLI and HTTP Tools

1. Purge all WordPress caches:

   cd /home/username/domains/example.com/public_html
   wp cache flush
   wp cache type    # Check if object/page cache is active

2. Benchmark with wrk or k6:

   wrk -t2 -c10 -d10s http://yourdomain.com/
   # or
   k6 run test.js

   Compare response times before and after cache clears.

Best Practices: Avoiding Double Caching

1. Decide Where to Cache Full Pages

Choose a single full-page cache: either at the web server (Nginx/Apache) or within WordPress (plugin). Do not enable both unless you have a coordinated cache purge mechanism.

2. Review DirectAdmin Web Server Templates

• DirectAdmin Nginx templates live in /usr/local/directadmin/data/templates/nginx_server.conf and per-domain custom directories.
• Apache custom templates are in /usr/local/directadmin/data/templates/custom/.
• Check for proxy_cache (Nginx), mod_cache (Apache) directives.
• If using a WordPress page cache, comment out or remove those lines in your template and reapply:

  sudo directadmin custombuild rewrite_confs

  Note: Rewriting configs may cause a brief reload/restart of web services; test on a staging server first.

3. If Using Web Server Cache, Integrate with WordPress Purge Events

• For Nginx, consider using the ngx_cache_purge module (if available) and a plugin like Nginx Helper in WordPress.
• On Apache, integrate cache purging via cache-purge scripts triggered by WP hooks (requires custom scripting).
• Document and test the full purge path: WP plugin → server cache → CDN.

4. Coordinate with CDN Settings

• Set Cache-Control and Expires headers in only one place (web server or plugin), not both.
• Configure CDN to respect origin cache headers or explicitly set CDN cache rules.
• If purging the CDN, automate purges after WordPress or server cache clears (using hooks or API integration).

5. Avoid Multiple Caching Plugins

• Only activate one full-page cache plugin at a time.
• If using an object cache plugin (Redis/Memcached), use only one implementation.
• Audit wp-content/plugins/ for overlapping functionality.

Step-by-Step: Safe Caching Architecture for DirectAdmin WordPress

1. Disable Web Server Page Caching (if using WP plugin):
   • Edit DirectAdmin Nginx template to comment out:

     proxy_cache_path ...
     proxy_cache ...

   • Apply changes:

     sudo directadmin custombuild rewrite_confs
     sudo systemctl reload nginx

2. Enable and Configure One Page Cache Plugin in WordPress:
   • Via WP-CLI:

     wp plugin install wp-super-cache --activate
     wp super-cache enable

3. If Using Object Cache (Optional):
   • Install and configure Redis/Memcached, but use only one at a time.
   • Example (Redis):

     sudo dnf install redis
     sudo systemctl enable --now redis
     wp plugin install redis-cache --activate
     wp redis enable

4. Test End-to-End Cache Behavior:
   • Clear plugin cache:

     wp cache flush

   • Check response headers:

     curl -I https://yourdomain.com/

   • Verify no duplicate cache headers and content updates as expected.
5. Document Your Caching Stack:
   • Keep a record of which layer is responsible for full-page, object, and CDN caching.
   • Document cache purge procedures for future troubleshooting.

Good Defaults and Practical Tips

• For most DirectAdmin WordPress sites: use plugin-based page cache and object cache (Redis), with static file caching by Nginx only.
• Do not enable proxy_cache for HTML in Nginx if using a WordPress page cache plugin.
• Use Cache-Control: private, must-revalidate for logged-in users to avoid inadvertently caching personalized content.
• Regularly audit active plugins and server configs after updates or migrations.

Summary: Double Caching—What, Why, and How to Avoid

Double caching in DirectAdmin-managed WordPress on Rocky Linux 9 usually arises from stacking caching solutions without coordination. The safest approach is to select a single full-page cache solution, ensure server templates reflect your choice, and rigorously test cache behaviors after any change. Automation (via hooks, scripts, or plugins) for cache purging across layers is necessary if you must use multiple caches.

Note: This article offers general technical guidance. Validate all configurations in a safe environment before applying them to production.

Previous: Why Page Cache Alone Is Not Enough for Logged-In Users

Next: Why Your WordPress Theme Is Slowing Down the Server