Optimizing Performance and Behavior with WordPress and the Sucuri WAF

Aside from providing significant protection from a wide range of threats, the Sucuri WAF also acts as a CDN due to its caching capabilities and regional PoPs — often performing even better than dedicated CDNs based on recent tests.

CDNs can significantly help speed up your website by storing and delivering content as close to the browser as possible, using servers dedicated to that task. What’s more, properly configured caching settings are the best defense against DDoS attacks. Even the heaviest DDoS can be easily mitigated by leveraging good caching.

With zero configuration, the Sucuri CDN is able to speed up your website by up to 60% — but you can leverage a number of settings to optimize the performance and behavior of your site.

Sucuri WAF Caching Options

Ideally, performance settings on the WAF would allow you to cache forever, but by nature WordPress sites have at least some dynamic content — for example, an ecommerce store, daily or hourly post updates, or a vibrant community with active comments. This means some compromises need to be made, and content that’s cached forever isn’t an ideal solution for all sites.

The WAF has four options to help you obtain the caching features you want, with Site Caching offering the best functionality for most scenarios:

Caching Level: Enabled

Enabled will always speed up a site, but this can be problematic for sites with frequent updates. This issue can often be resolved using the feature found in our WordPress plugin located on tab /wp-admin/admin.php?page=sucuriscan_firewall#clearcache.

Another problem is that user sessions may not be respected with this caching level. This means that if you have a feature where regular users (not admins) are required to log in, they could see other users’ content. As a result, Enabled is ideal for sites who don’t have active users logging in or carts.

Caching Level: Minimal Caching

Minimal Caching works out well for sites with regular updates, but like Enabled, will not respect user sessions.

This option is best suited for sites with frequent changes but who also do not have regular logged in users or carts.

Caching Level: Site Caching

In nearly all cases, Site Caching combined with properly defined cache control headers offers the best solution for all websites.

You can set any cache settings on the WAF that suit the site — for example, if a post or page is older than X days and is unlikely to ever change, you can set it to cache for a year using the correct cache control header.

We have a great post here on how you can investigate cache control headers.

Unfortunately, WordPress does not come with good cache control headers by default, so setting the WAF caching level to Site Caching could negatively affect performance.

Cache control headers can be set in the site’s code. For example, in the PHP theme files:

<?php

header("Cache-Control: max-age=86400");

?>

Or, in Apache’s .htaccess:

<filesMatch ".(php)$">

Header set Cache-Control "max-age=86400, public"

</filesMatch>

In Apache’s config files (above .htaccess example would also work):

<IfModule mod_headers.c>

<FilesMatch "\.(php)$">

Header set Cache-Control "max-age=604800"

</FilesMatch>

</IfModule>

And in the Nginx config file:

location ~* \.(php)$ {
expires 1d;
}

Important caveat: These are examples only and not to be considered comprehensive. You should refer to your server’s documentation on setting header directives for specific details.

Caching Level: Disabled

The Disabled caching level option adds 60 seconds of page caching time when no cache control headers are detected. This level is ideal for troubleshooting caching or compression issues, and should not be used on an ongoing basis.

Caching Policies with Cache-Control

An excellent plugin I have used a number of times to complement Sucuri’s Site Caching setting is Cache-Control By Daniel Aleksandersen.

Cache-Control comes with extensive documentation on cache control headers, which can be helpful for understanding and configuring the very granular cache control directives it sets in your WordPress site code.

Managing Static Content with File Versioning

Another issue which can come up is static content.

While you may have good control now over the static content on your site using cache control headers and our plugin to clear the cache of pages and posts automatically on posting, unless the entire cache is cleared on the WAF using this method static content such as image files, .pdf, .js and .css remain persistent as they are cached regardless by the WAF for 72 hours.

If you want to avoid clearing the cache on making changes to static files and also avoid old versions being cached by browsers (including your own), use a technique called versioning.

WordPress already does this automatically with their own files when you upgrade any core files or themes by adding the version number as a parameter after a ? such as:

style.css?version=1.0

To easily accomplish this, you can use the same Enqueue versioning method described here. There are also a number of plugins which will do this versioning for you, such as Autover.

Versioning removes the need to clear cache, so clearing cache fully might never be required. This means your older pages could be being cached indefinitely, speeding up the crawl rate of any visiting bots and lessening the load on hosting servers.

Final Comments

I’m often asked, “Do we still need caching on the host?” And the general answer is:

If it’s not causing issues, more caching is good and caching on the host should speed up delivery to the WAF servers.

There are multiple layers involved. Apache, Nginx, and MSSql all have caching options which can be discussed with your hosting provider — and WordPress itself has a large number of caching and optimization plugins. These levels of caching should not be confused with cache control or the WAFs own caching.

If you need help optimizing the performance and behavior of your WordPress site, we’re here to help. You can refer to our handy documentation for options or submit a support ticket to get started.

Comments or feedback about the WAF? Shoot us a message at cloudproxy@sucuri.net.