Caching of your site tends to create a superior user experience as pages are served to your site visitors more quickly. In the modern technological world of “NOW!”, where we expect our requests from technology to delivery immediately, anything that takes longer than a few seconds to deliver what the user asked for is considered slow, useless, or obsolete.
Caching of live WordPress sites is something that used to be a rare occurence. With more informative articles, better hosting companies, and the user community “leveling up” their technical expertise, caching of WordPress sites has become more commonplace than ever before. That is a good thing.
Many other web presence services and hosting companies have deployed caching for years. Some are more advanced than others with their deployment process. The better web presence platforms will manage flushing the cache for you.
If you are managing your own hosting and caching solutions here are some things we’ve encountered on our own WordPress sites and MySLP deployments.
Security or Proxy Service Caches
A security or proxy service is a “website request agent” that sits between your site and the real world. It is like the bouncer that only lets the “good people” gain access to your site. Many, like Sucuri, also have performance options built in. These “performance” settings are a proxy cache. They store a copy of the non-dynamic pieces of a website like CSS and sometimes JavaScript on their servers and send those resources from that copy.
That means you will need to clear these third party caches any time you update your site with something that changes the CSS or JavaScript. Some caching services are more aggressive than others and cache ALL JavaScript files and CSS files. Some are great at detecting file changes immediately while others could take an hour, day, or even a week to detect the changes.
The general rule of thumb we go by is any time we do a major software update, clear the Proxy Service Cache.
Our proxy service has broken the JavaScript component of MySLP as the script they serve is out of sync with the back end payload that is sent. It happened once and after a few hours of debugging we found the script going to a “random site visitor” was different than our production code. Clearing the proxy service cache is now part of our standard production system update process.
System Code Caches
Speeding up the execution of code can be done with various server-side technologies. For our WordPress deployments we often deploy OPcache. All of our hosted PHP code uses this service to “remember” the code for the most-accessed PHP files and store it in fast access memory (RAM on most servers). This eliminates a lot of file open/close requests which is still one of the slowest processes a hosted application performs even on solid state drives. PHP code execution is much faster withOPcache in place.
This also means that updating ANY PHP code on the system requires anOPcache flush. Doing this is easy but, like the proxy service cache, remembering to clear this cache is something that must be added to standard production system update processes.
We recently updated the Experience component along with a base upgrade of Store Locator Plus. The sites broke with a fatal error that took down the site because a specific function required by the older Experience code was missing. The problem was the opCache had the old code forExperience, not the newer code that referenced the replacement function instead. Clearing theOPcache brought evertyhing online immediately.
Web Browser Caches
Web browsers all come with some level of caching enabled by default. Some browsers, like Safari, are hyper-aggressive with caching. The browsers are also doing a lot more performance tricks to “beat the competition” by pre-fetching pages based on search histories before you even GO to the page. This can throw off proxy service caches and opcache requests as your web content may have loaded in some browsers, Safari seems to be the most egregious in this regard, BEFORE you cleared those caches and stored the page locally with the broken pre-flush version.
Nearly all browsers are aggressive at caching CSS and JavaScript these days. Doing a force page reload, holding down shift and clicking the reload icon in the address bar on most browsers, often helps clear basic cache-related issues. However more complex sites may require even “deeper cleaning”. Clearing your browser history and related files often helps but can clear stuff out from sites you want to be remembered at.
We find that using the private mode browsing is a good litmus test to see whether browser-side caching is causing problems. Private mode starts with a clean slate. No cookes, no cached web content of any kind. If private mode fixes your web experience then browser caching including CSS, JavaScript, or cookies is likely the issue. Clearing the history for the specific site you are visiting can help. Often, however, today’s websites pull content from several different service which means clearing just the stuff from www.storelocatorplus.com for example does not clear the map content coming from maps.google.com. Often we get away with clearing only those things that updated in the past hour if clearing a single site doesn’t work.
Caching Is Not Always The Problem
While caching is not always the problem when a web experience goes wrong, we find more-and-more often that our customers “forget to clear the cache” after doing a software update of Store Locator Plus. Our MySLP users have far less issues in this regard as we ensure that several levels of caching are cleared every time we update the production software; they can, however, still encounter issues with browser caching or the content that contains the location maps if they have not cleared their Bootstrap server-side caches for example.