Series: WordPress Performance on DirectAdmin (Rocky Linux 9)

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

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

Introduction

Page caching is a fundamental performance technique for WordPress, especially in high-traffic environments managed via DirectAdmin on Rocky Linux 9. For anonymous visitors, full-page cache can drastically reduce server load and response time. However, for logged-in users—such as admins, editors, or eCommerce customers—page cache alone is insufficient and can introduce data leakage or broken functionality. This article details the limitations of page cache for authenticated sessions, DirectAdmin-specific considerations, and practical strategies to safely optimize performance for logged-in users.

Understanding Page Cache and Its Limitations

Page cache stores the full HTML output of a page and serves it to subsequent visitors, often bypassing PHP and database processing. In DirectAdmin-managed WordPress on Rocky Linux 9, this typically leverages either:

• NGINX or Apache FastCGI/static file serving (via custom template includes)
• PHP-based cache plugins (WP Super Cache, W3 Total Cache, etc.)

While this is highly effective for anonymous traffic, it fails for logged-in users because:

• Personalized data (admin bars, WooCommerce carts, user dashboards) varies per session.
• Caching plugins and proxies must bypass cache for users with authentication cookies.
• Serving cached pages to the wrong user risks session leaks and data exposure.

DirectAdmin-Specific Considerations

On DirectAdmin with Rocky Linux 9, page cache is often integrated through webserver templates and PHP-FPM pools. Key points to consider:

• PHP-FPM Pools: Each domain typically has its own PHP-FPM pool in /usr/local/directadmin/data/users/<user>/php-fpmXX.conf. Ensure the configuration is tuned for concurrency, but know that page caching won’t reduce PHP processing load for logged-in users.
• NGINX/Apache Templates: Custom cache rules are usually injected into /usr/local/directadmin/data/templates/nginx_server.conf or apache2.conf. Bypass rules for logged-in user cookies must be explicit.
• Per-Domain Tuning: DirectAdmin allows per-domain overrides. Never assume global cache rules are safe for all WordPress installations, especially multisite or WooCommerce stores.

Risks of Relying Solely on Page Cache

• Session Data Exposure: Cached admin or personalized pages may be served to the wrong user if cache rules are not strict.
• Broken Functionality: Plugins and themes may rely on fresh PHP sessions, AJAX endpoints, or nonce values that are invalidated by cache.
• CSRF and Security Risks: Nonces and authentication tokens are user-specific. Caching these can lead to cross-user attacks.

Mitigation requires more nuanced caching strategies, typically involving:

• Bypassing full-page cache for all authenticated requests
• Leveraging object caching, opcode caching, and selective AJAX caching

Verifying Cache Bypass for Logged-In Users

To ensure cache is correctly bypassed for authenticated sessions, use the following methods:

1. Login as a user in a private browser window.
2. Check response headers with curl:

   curl -I -b "wordpress_logged_in_<hash>=cookie_value" https://example.com/

   Look for X-Cache: MISS or absence of cache headers.
3. Examine logs for cache bypass:

   sudo tail -f /var/log/nginx/access.log

   or

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

   Confirm authenticated requests hit PHP backend.
4. Benchmark with wrk or k6 using authenticated cookies to simulate load:

   wrk -c10 -d30s -H "Cookie: wordpress_logged_in_<hash>=cookie_value" https://example.com/

Checklist: Safe Caching Configuration for Logged-In Users

• Bypass page cache for requests with wordpress_logged_in_ or wp-postpass_ cookies.
• Never cache admin screens (/wp-admin), AJAX endpoints (/wp-admin/admin-ajax.php), or WooCommerce cart/checkout pages.
• Use opcode cache (opcache) for PHP (safe for all users):

sudo dnf install php-opcache
sudo systemctl restart php-fpm

• Enable persistent object cache with Redis or Memcached:

sudo dnf install redis
sudo systemctl enable --now redis

Install a plugin like Redis Object Cache and activate with WP-CLI:

wp plugin install redis-cache --activate
wp redis enable

• If using NGINX, add cache bypass rules in the domain’s custom config. Example for DirectAdmin NGINX:

map $http_cookie $skip_cache {
    default 0;
    ~wordpress_logged_in_ 1;
    ~wp-postpass_ 1;
    ~woocommerce_items_in_cart 1;
}
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;

• For Apache with mod_cache, similar bypass logic is required in .htaccess or site config.
• After changes, always restart affected services:

  sudo systemctl restart nginx
  sudo systemctl restart httpd
  sudo systemctl restart php-fpm

Step-by-Step: Implementing Safe Caching for Logged-In Users

1. Install Required Packages
   • PHP opcache and Redis for object caching:

   sudo dnf install php-opcache php-redis redis
   sudo systemctl enable --now redis
   sudo systemctl restart php-fpm

2. Configure Redis Object Cache in WordPress
   • Install and activate plugin:

   wp plugin install redis-cache --activate
   wp redis enable

3. Update NGINX/Apache Templates
   • Edit NGINX custom config for cache bypass:

   sudo vi /usr/local/directadmin/data/templates/custom/nginx_server.conf

   • Add the map block and fastcgi_cache_bypass (as shown above).
   • For Apache, update .htaccess to add CacheDisable for sensitive paths and cookies.
4. Restart Services
   • Restart web services to apply changes:

   sudo systemctl restart nginx
   sudo systemctl restart php-fpm

5. Test Cache Bypass
   • Login and verify with curl and log tailing (as described above).
   • If in doubt, temporarily increase PHP-FPM pool logging:

     sudo vi /usr/local/directadmin/data/users/<user>/php-fpmXX.conf
     # Set log_level = notice

     Warning: Higher log levels can fill disk quickly. Revert after testing.

Performance Tuning: Good Starting Values

• PHP-FPM pool process settings (per site):

pm = ondemand
pm.max_children = 10
pm.process_idle_timeout = 10s

• For Redis:

  maxmemory 256mb
  maxmemory-policy allkeys-lru

• OpCache settings (in /etc/php.d/10-opcache.ini):

opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1
opcache.revalidate_freq=60

Conclusion

On DirectAdmin-managed WordPress installations with Rocky Linux 9, relying solely on page cache for logged-in users is neither safe nor sufficient. To ensure performance and security, combine careful cache bypass rules, persistent object caching, and PHP opcode cache. Always validate with real user sessions and logs before deploying to production. Use per-domain DirectAdmin templates and PHP-FPM pool tuning to tailor resource usage for each site.

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

Previous: Cloudflare + WordPress on DirectAdmin: Correct Setup Without Breaking Admin

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