Caching Explained

Do you sometimes have problems when your Weaver Xtreme or other plugin settings won’t show up after you save them?

As explained in other articles, this is very commonly caused by caching issues. Caching is a process that tries to make your site load faster by saving what should be static, unchanging resources such as images, CSS files, and JavaScript files in a cache closer to the end user. This can be anywhere on the delivery stream from the site server to the end user.

The main problem with caching for site designers and developers is that caching can prevent current changes (such as changing Weaver Xtreme settings) from being properly displayed.

Browsers are the closest to the user, and a very logical place to do this. So when a user loads a website that they’ve recently visited, much of the content will be already saved in the browser cache. Most of the time, this is a good idea and results in faster loads. Chrome is notoriously aggressive when it comes to caching.

Other places to cache are on your WordPress host. WP caching will try to deliver static HTML instead of the slightly slower dynamic content generated by PHP. This can be a good idea and increase your sites speed, especially from slow, shared hosts. You generally have control

Sometimes your hosting company will try to do something similar, and provide its own caching. This is still somewhat rare, but for a hosting company makes sense as it tends to reduce the bandwidth they need to provide.

In the middle are content delivery systems. Maybe the most well-known example is CloudFlare. This in-the-middle caching approach saves content on the providers servers, usually all over the world. For the most part, CloudFlare caches images, but can cache CSS and JS. When developing on a CloudFlare served site, you have the option of temporarily entering development mode and purging the existing cache.

WordPress JetPack is yet another example of caching – but very specialize to images. JetPack has a feature that will upload your site’s images to supposedly fast WordPress.com servers, and then deliver them to the end visitor from there instead of your own server. Issues with this service can manifest if you replace Media Library images directly.

What about the “Remove Query Strings From Static Resources” plugin?

There is a WordPress.org plugin available called Remove Query Strings From Static Resources that is intended to improve your site’s performance by removing what are really version identifiers attached to normally static CSS and JavaScript resources.

In theory, that plugin should not affect a stable production site. If you were fiddling with your menu or changing Weaver Xtreme settings, then that plugin could likely “break” things.

Essentially, the standard core WordPress engined adds a version identifier to all CSS and JavaScript files, something like this:

https://weaver-based-site/wp-content/themes/weaver-xtreme/assets/css/style-weaverx.min.css?ver=3.1.3

The goal of the version number is to allow caches to load the latest version of the resource if the version number changes.

It is that ?ver=3.1.3 on the end that is the target of the “Remove Query Strings” plugin. When a version string like that is added to the end of a .css or .js file, then “lazy” caching algorithms will never cache that file. Others are more more clever and also cache the version number so they can cache versioned resources.

With Weaver Xtreme Plus, whenever you change a setting, the newly generated style file will have a different version number. This is intended to cause the file to be reloaded with the latest version, and is a good thing. But if some lazy caching system simply doesn’t cache any resource with an added version, that reduces performance of your site. Using base Weaver Xtreme, or checking the Weaver Xtreme Plus “Use Inline CSS” option will largely avoid this issue when changing Weaver Xtreme Options.

Many site “evaluation” resources recommend removing such version strings, and thus the plugin in question.

What does this mean for you? It means that if the version strings are removed, any live updates you make when changing Weaver Xtreme or even other plugin options may not “take”.

So just be aware of this. If you have any sort of caching plugin, or other plugin that is supposed to improve your site’s speed, it is highly likely you will have to disable them during development. These issues generally do not apply to creating content such as posts or pages – just to changing site styling.