With the change in Google’s site rating and ranking criteria, the reasonably new “Web Vitals” measurements have generated new interest in a variety of caching technologies to improve content delivery times in the never ending race to the elusive “100% across the board” and satisfactory search engine indexing results.
While this is admirable, it has also generated quite some confusion, misconfigurations, poor performance and frustration for many. If you are considering using minification or caching on your site, ensure that you have followed the best practice optimisation methods for layout, images and extension use first, otherwise you may not see the results you were expecting.
What is caching?
Caching is when a static version of data, or in this case your Joomla website or page, is generated containing the content as of that current moment in time. This stops the server from querying the database, crunching data or formatting the page on every visit to that page; instead it loads the pre-formatted “cached” version. The idea is that if the database and other resource queries are removed then the page load and formatting time is drastically reduced, serving your site content faster to the visitor and providing a better user experience. Sounds like the utopia of web site delivery, doesn’t it?
Potential downsides of caching
Beware, there are potential downsides to minification and caching, some content can become “out-of-date” or “stale” for a period of time. This is absolutely fine if your content is fairly static and doesn’t change very often, or is not time-sensitive. However, if you are producing pages with time-sensitive data or related content items such as foreign exchange rate, trading, statistical data sites or even e-Commerce sites where competitive and up to date pricing is important, then the choice to cache or how to cache must be very carefully considered to avoid inconsistency or confusing output.
Depending on what level of caching you choose to use will determine whether large datasets or highly related content are in sync and make sense to your visitor. With larger datasets or content, there may also be a performance loss if your server or hosting account does not have enough resources or processing power to perform the data caching activity behind the scenes. Subsequently as visitors browse through your site your page load times can actually increase as visitors are always waiting for the cache application to build the cached page before displaying it. Having said this, if your site architecture means that your visitors tend to revisit the same page multiple times within the same session, like central hubs or portal type sites, then caching can produce ideal results and improve load times.
When should you consider caching?
Ok, let’s start in reverse. Caching will not be the “golden bullet” to poorly configured or cheap hosting performance (sorry, your $2/year shared hosting probably won’t benefit much from caching). It also will not be the ultimate solution to loading large or highly graphical pages super fast (sorry, your 10 year old photo portfolio on one page, probably won’t benefit much from short-term caching either). So, when should you actually consider caching? If your site and its content is reasonably static, by this I mean existing content isn’t updated or modified regularly, or new content isn’t added constantly.
This is not to say that rapidly changing or very dynamic sites don’t benefit from caching, but their cache & CDN (Content Delivery Network) policies will tend to be much lower and tailored to their needs and time-frames, more so than the average site and will be targeted more at older content caching with exceptions for newer content.
In some cases, simple but effective use of compression or minification extensions can produce better results due to less pressure on available hosting resources, not to forget proper optimisation of image dimensions and file sizes.
At this point it is worth mentioning “pre-caching” and “progressive web applications” (PWA), this is when the website is designed specifically to proactively download the next anticipated page that most visitors access to a device before it is requested. These technologies are often targeted at mobile devices and sites where visitors return regularly, maybe to check a status or the start of an event.
Where to start with caching
If your site might be considered to be small or medium and you have invested wisely in good hosting, in reality you shouldn’t need anything more than enabling SSL & GZip in Joomla or mod_deflate and mod_expires browser caching to obtain good user-experience or “Core Web Vitals” via Google, especially if your site is Joomla 4. Connection compression, Lazy Load for image heavy sites and browser caching policies combined with good site layout and hosting should provide for mid-90’s vitals. If you are looking for that little extra boost, html minification and CSS/JS combining extensions can turbo charge your user-experience without adding too much resource usage.
If your site tends on the larger side or if dynamic content database queries tend on the larger side, then database query caching and/or OPCode caching might be the better choice over page caching extensions, potentially still making use of compression or minification utilities to reduce static resource loading times too.
In cases where your site is very large (enterprise or scientific type of content) and the content is more “data centric”, with large tables or lists of related information that may be searchable or can be filtered by visitors, then the likes of Redis or Memcached might be a preferred option. Using these options requires quite a lot more understanding of your data architecture and you will be more likely to be running a dedicated server, VPS (Virtual Private Server) or Cloud Virtual Server instance rather than using a shared hosting account.
Whilst both of these are considered to be “caching” applications, they operate more like in-memory indexed data-stores and are object based, rather than whole page file based caches therefore allowing individual data objects to be updated dynamically without invalidating the whole cache for any single page. For these reasons, these are more enterprise level architectures as opposed to small to medium website implementations.
The common pitfalls of caching
First rule of Cache-Club is “less is more”. By this I mean, don’t randomly mix different layers or levels of compression, minification and cache technologies without testing individually first. Mixing multiple technologies and methods tends to interfere with each other and cause contention. Cache technologies combined with compression and minification technologies can be a good thing, if done in the right order and if they are aware of each other to some degree; otherwise compressing or caching something that is already compressed or cached can actually grow in size, delivering the exact opposite result than what you are looking to achieve.
Understanding optimum caching configuration is more complex than it would initially appear, the “more the merrier” approach more often than not delivers a “more is absolutely awful” and “it broke my site” outcome, unfortunately.
There are many types, varieties, levels and layers of caching, not all suit all types of content and sites, in many cases “none” can actually be the best answer and often a limited combination, in the right order can produce the desired “gold bullet” brilliant results.
So, in short, for those that may not be well versed in server, application, php or Joomla! Performance configuration or tuning, this is a mine-field waiting to explode, not to mention ruining and frustrating your day.
Navigating the cache minefield
As the book says, in large friendly characters, “Don’t Panic!”...
There are some basic “Do’s and Don'ts” that can be considered in order to reduce your stress.
- Don’t “throw everything but the kitchen sink”(1) at the problem, you’ll either observe contention or not be able to determine what is working and what is not. (ie: Don’t break the first rule of Cache-Club)
- Don’t host on the cheapest hosting plan with the largest disk space offer, these tend not to be tuned for performance but for maximum return on the hosts investment.
- Do talk to your host to see what, if any, resource limits may be in place (PHP memory_limit, MySQL max_user_connections, Query Cache, MemCache, I/O entries/exits (basically, reading and write from disk), virtual or physical hardware limits (RAM/CPU/Cores).
- Do test each cache or minimiser extension and server caching option separately first to get a baseline, including CDN’s.
- Do document your testing, so you can keep track of not only the results but also what combinations you may have already tried.
- Do look at the graphs and waterfalls that most of the page speed testing sites provide to find anomalies, especially those affecting Google's Web Vitals LCP (Largest Contentful Paint) and FCP (First Contextual Paint).
- Do try and understand what is actually causing the performance issue and check all pages, not just your homepage.
- Do optimise your site layout, structure and images before deciding if you really need caching enabled, not to mention reducing the use of unnecessary or excessive extensions or large Javascript libraries for the use of one “cute” feature.
As mentioned above, in most cases, “less is more”, throwing everything but the kitchen sink(1) at a poorly performing site without understanding why it is under-performing may not only increase maintenance requirements but can also completely trash what reasonable performance you may have been observing.
As with all generic and starter articles, we aren’t able to go into specific application or extension configuration, but simply provide you with a starting-point to further research your own requirements. Keep in mind, not all servers are equal, especially shared hosting accounts and not all sites are equal depending on the content types, use case and extension use.
Your use of cache and it’s results may vary vastly. Ultimately the best configuration is a well sized and configured server and applications to suit your needs, no amount of caching will completely overcome a poorly configured or cheap hosting environment. The following provides a brief overview of some of the different cache, compression and minification options available:
- Joomla GZip
This Global Configuration option compresses the data-stream between the web-server and the browser, in most cases this is generally a good option to enable, unless your hosting offers LiteSpeed Caching (LSCache), Varnish or similar proxy caching as these server utilities will generally take care of that for you. - mod_deflate
If installed, this web-server module can compress specific assets and allows you to set long cache time directives to influence how long the visitors web browser should cache an existing local copy of an asset or whether it needs to re-download the asset from the site again. If not enabled by default on the host, you can use a .htaccess or web.config file to invoke mod_deflate and choose which assets to tell the browser to cache and for how long. Talk to your web host to determine if mod_deflate is installed on your server. - Joomla! Site and/or Page Cache
Joomla Site cache tends to be best for static pages and will be applied across the whole site equally, Joomla Page Cache plugin is a little more specific and will statically cache individual pages including module and plugin data, so is only particularly useful for highly static sites and modules that are not dynamic or random by nature. - 3rd Party Cache/Performance Extensions
These tend to come in the form of Joomla plugins, with most offering both compression/minification and caching options and some offering differing levels of each from minimal through to aggressive. Hosting accounts with larger resources available are more capable of running aggressively, whereas lesser resourced servers may struggle to complete the compression or cache task in an acceptable time potentially causing high TTFB (Time To First Byte) issues. To that end, you may actually find that less aggressive caching or compression quite often produces better results. - PHP OPCode/OPCache & MySQL Query Caching
These are server application based cache utilities and generally are not aware of Joomla extension cache activities. If these are enabled it’s probably a good idea to disable Joomla or 3rd Party extension based cache options to avoid contention or “double-caching” activity. Making use of these functions is best for sites that heavily utilise PHP based processing or heavy, but regular SQL Query type sites. In some cases these can be good for eCommerce or high custom-field usage sites, caching DB Queries, but not directly caching the page generated by the query. - Caching & Proxy Servers
These environments include the likes of the LiteSpeed Caching Server or similar applications to Varnish Proxy Servers. As a general rule, let these applications do the heavy-lifting unhindered, so disable Joomla GZip, disable both Joomla Cache utilities, limit 3rd Party extensions to “minification” and not cache or compression, remove any .htaccess GZip or mod_deflate entries and ensure any mod_expire statements match the time-frames configured within the Cache/Proxy Server. - Hosting Virtual Container & Resource Managers
Here things can get a little “hairy”. For the most part, virtual container and resource management applications such as CloudLinux Manager or MySQL Governor are best left to their own devices with default configurations, and on-board Joomla compression options and 3rd Party minification and cache extensions work best, within reason. You may bump into resource limitations, imposed by the virtual environment manager application, that limits the effectiveness of any external caching function, so this is a little bit of a “how long is a piece of string?” exercise, you’ll need to trial, test and error here to find the best options. - Content Delivery Networks
CDN’s can vastly improve performance by the very nature of their architecture. Particularly for internationally busy sites, there may be no further need for caching options purely because of the delivery mechanism being distributed around the world but for local or purely regional based sites CDN’s may adversely affect performance or have no effect at all. However, for large sites, a combination of GZip, mod_deflate and a simple page cache may also drastically improve poorly responding servers (slow TTFB - Time To First Byte), especially if caused by large SQL queries or large numbers of portfolio style images. The use of additional proxy caching in front of a CDN can seriously adversely affect “administrator/” performance due to multiple caching and constant cache invalidation, particularly for regular addition of articles.
This article barely scratches the surface regarding caching and performance techniques, especially with regards to large SQL database (data-centric) sites, high traffic sites or very graphical (portfolio or analytical) sites, these sort of “Enterprise Level” sites require systems analysis, File-System Tuning and Database Tuning activities before determining the “Caching Strategy” required.
We do appreciate that this article has not given you any definitive answers or “golden bullets”, but we do hope that it may have given you a better understanding of what you might be trying to achieve and the best way to approach it. (What’s the first rule of Cache-Club?)
Footnote: (1) to “throw everything but the kitchen sink at it” is an English language idiom, commonly used to humorously describe a situation when everything and anything, even unrelated actions, are taken at the same time in an effort to achieve a goal, but normally ending badly. A similar US English language phrase is “using a scattergun approach”.
Article Contributions: Thanks to Anja de Crom for copy~ & proof~reading all my articles, without her writing expertise and international experience and patience with me, this article would not have been possible.
Further Reading:
JCM - Joomla 4 Performance - https://magazine.joomla.org/all-issues/october-2021/the-new-metrics-for-web-performance
Melbourne JUG - Improve Your Lighthouse Scores -
https://joomla.org.au/news-articles/australian-virtual-user-group-events/avjug-april-2021-google-lighthouse
JCM - What Is A CDN and How To Implement One In Joomla -
https://magazine.joomla.org/all-issues/january-2021/what-is-a-cdn-and-how-to-implement-a-cdn-in-joomla
JCM - Using Native LazyLoading On Your Website -
https://magazine.joomla.org/all-issues/january-2021/using-native-lazyloading-on-your-website
JCM - Joomla SEO checklist -
https://magazine.joomla.org/all-issues/may-2021/joomla-seo-checklist