WPEngine caching + ACF Option field updates: Which cache is the culprit?

Question

On a site hosted on WPEngine, I have all options for caching turned on. Recently, site editors/managers have been making updates to the site that are not consistently rendered on the front end. (On some browsers the updated content shows, on some, the prior content shows). The "Clear all caches" button in the WPEngine settings tab in the CMS resolves this issue… until the next time it comes up again.

The content we've experienced this with is specifically via Advanced Custom Fields options fields (which are used to display site-wide header/promotional messaging). I don't know if that's the only content with this issue — it's just the content that's most frequently updated, so the one that's been observed as such.

WPEngine allows enabling: Page Cache, Object Cache, Network Cache, "Smarter Cache" (which allows "posts and pages to be cached for longer if they haven't been modified in a while"), and Last-Modified headers.

I'm trying to figure out where I need to cache less aggressively so this stops happening. I figure it could be an Page cache issue (as individual page content isn't updated, but rather just printed to the header.php file via the get_field() function), but then I assume content would be consistently update (or not) across all browsers. So I'm leaning toward it being a Last-Modified headers issue, as it appears to be affecting how the browser loads the page.

Does this sound like the correct evaluation? Are there any sure-fire ways to go about diagnosing and confirming this other than trial/error?

Answer 1

For a completely accurate answer you'll need to ask WPEngine for support, but there's some general things to consider.

Normally when you visit a WordPress page, the WordPress PHP application needs to run so it can retrieve the content from the database and render it using your theme's templates, and this involves loading and running plugins in case they affect the final page. This can be slow, so most implementations of 'page caching' will take the final rendered result and save it as an HTML file so that it can use this to serve the page for future visitors without having to run WordPress every time. The performance improvements of this approach are significant.

Since a static HTML file is now being served to visitors, any changes made to the page since that file was created will not be seen by users who are being served the HTML version. The solutions to this problem that caches usually implement are to periodically delete the HTML file so that the cached version is kept up to date (how often this happens depends on how the cache is configured), and to delete the cached file any time the page is updated.

The problem you're having is that you're using ACF Option fields. These fields essentially save their data as site-wide settings, rather than post metadata. Since you're not updating a specific page the cache can't know which pages will be affected, if any, so it won't delete any cached files, and you're left to clear the cache yourself.

If your fields are controlling site-wide content, and it's very important that any changes are immediately visible, then you need to make clearing the page cache part of your workflow. If you want this to happen automatically, then you'll need to check with WP Engine how you can automatically trigger their page cache to clear, as I don't believe there is a single solution that will work for all caching implementations.

The problem with clearing the entire cache every time you make a site-wide change is that every time you do this your site is no longer cached and the next wave of visitors are going to experience slower load time as the caches of many of the pages they visit for the first time will need to be regenerated. Better solutions would be to use AJAX to load any site-wide content that frequently changes, or to just let the cache expire automatically and accept that some changes will not be immediately visible.