Caching is becoming more and more important if a website needs to be performant and able to scale easily. The last thing you probably want is your cache not functioning properly. There are multiple ways your cache can fail you. In this article we’ll show you some of the ways why caching is not working and how you can take care of them.
When cache is not working as expected, the first thing you want to check is to see wether any caching is happening at all, and where it is being stored. You can check this by taking a look at the HTTP Cache Headers sent with each request. That way you’ll have an idea on where to look on what’s going on.
Reason 1: setting a session cookie
Oftentimes we see sites setting a session cookie to each and every visitor. Even though this may be intended behaviour, for keeping track of a cart or wishlist for example, it will break the cache of your site. Each session is unique and will therefore not be cached. Setting a session cookie while it is not yet needed will cause your site to be less performant and scalable than it can be.
So, how do we fix this? First: make sure you’re only setting a session cookie when it’s needed. This way people browsing the site and not really interacting yet can get served their pages straight from the cache. The performance boost they get just might help them to add your products to their cart, and that’s when the session cookie should be set.
If you’re unaware of setting any session cookies, your site might still deliver them. Most likely a plugin is causing this behavior, even if you’re unaware. How do we find which one? Look through the plugins folder and search for the PHP function session_start() in the source code of the plugins. This function is used to start a session using cookies. It’s not guaranteed that every plugin that has this code in it will be setting cookies, but it at least gives you a place to start looking.
Reason 2: use .htaccess incorrectly
Sometimes people try to alter the caching behavior of their site by adjusting things in the .htaccess file. When this is done incorrectly it might have strange and unpredictable behavior. In general, at Servebolt there is no need to alter the caching headers this way. And when you’re using Accelerated Domains, we’d even recommend against that.
Reason 3: not updating static content correctly
By default, most caching environments will cache static content (CSS, JavaScript, etc.) by default for a longer period of time. Updating the resources at origin will cause an older cached version of the resource still to be served while the cache is still valid.
The easiest way around this is to add version strings to the requested file. This is not only good because it bypasses our server-side cache, but it will also bypass any browser-cache the visitor might have in place. Keep in mind that the old version string might still be in the server cache, so that needs to be purged before it becomes visible.
Reason 4: Setting incorrect caching timers
Cloudflare Edge cache does exactly what it is instructed too which is usually good whenever you don’t do updates to your site. An example would be to have set Browser Cache TTL to four hours. Then visitors wouldn’t see the updated version of your site for at least four hours since the cache was last refreshed. The simplest fix would be to set your site to dev mode in the Cloudflare caching settings whenever you’re doing updates. Dev mode will turn off all your set caching settings.
Reason 5: Disable all cache and still see cached content
Sometimes, even when all caching is turned off at Servebolt and within Cloudflare, you might still not see the updated version of your site. This can be many things but the most common case is that your browser caches the content. This is simply fixed by going to your browser settings and clearing cache and cookies.
Any of the reasons outlined above could be attributing to caching not working. It’s also very well possible that it’s due to a combination of more than one reason. Happy debugging!
