Joomla 4 is a major improvement over Joomla 3. Right out of the box you get a very fast CMS with built–in support for structured data (what was formerly called “microdata”), even several caching options to cater for any use, from lightweight persona sites to massive, busy portals.
For reasons that have to do with its very old, past iterations it still has the unwarranted bad reputation of a slow, bad for SEO CMS. This could not be further than the truth. In fact, Joomla 4 without any third party software outperforms its competitors even when aided by purpose–built third party software.
In this series of articles we will discuss how you can tune up a Joomla 4 to improve it performance even more and how to avoid all the pitfalls when building your or your client's site. The end result is a site that's appealing to both search engines and living, breathing site visitors.
This five–part series is an update to my Joomla 3 performance tuning series from last year. I am happy to be able to share this series with the Joomla community through the Joomla Community Magazine. Many thanks to the wonderful volunteers who made this possible!
In this first part of the series we'll talk about why this is important, in general, and what are the obvious first steps you can take to get to that goal.
Why do you even need a fast site?
Before we embark on our adventure in optimizing the performance of your Joomla site we need to address the most basic question: why does it even matter? After all, we are talking about you having to do more work before proclaiming your site ready for publishing. Is this really worth the effort even if it already attracts a decent amount of organic traffic and feels speedy to you?
I strongly believe that it is absolutely worth the time, both for philosophical and practical reasons.
The first philosophical reason is that a slow site is a wasteful site on many levels. It wastes everyone's time. Waiting 4–5 seconds for a page to load may not sound that big of a waste but over the course of a year and hundreds of thousands of pages each one of us is waiting to load we are collectively wasting entire person-years of our time. All the while we are wasting electricity to generate the content slower than it needs to, deliver more data than we should, and process it slower than necessary for display with everything that entails about the environmental footprint of your site.
The second philosophical reason is that slow sites are exclusionary. They are harder to reach by underserved communities who rely on high–latency or slow Internet connections. Be it the satellite Internet that's the only feasible link to the outside world in an African village or the weak WiFi in a McDonald's parking lot in a poor school district in the USA, the slow site may be creating an intangible but very real barrier between its content and the people who could be consuming it and benefiting from it. Just because most of us are privileged enough to live in urban centers in developed nations with fast, low–latency Internet connections doesn’t mean we should be acting as gatekeepers to information by omission of doing something relatively easy to increase the reach of that information. This is especially important if you are developing non–profit, educational, governmental or other resource websites.
As for practical reasons, let’s start with the obvious problem that a slow site creates a frustrating experience to the visitor. They are likely to give up on your site and visit someone else's. If they stay, they are likely to be in a negative frame of mind after being subjected to a series of long and unnecessary delays. This weakens and hurts your site’s content, discourages repeat visits and reduces your conversion rate.
The second and most important practical reason is that search engines no longer rank your site based on content and connection to other sites alone. They take into account the Core Web Vitals. Essentially, a site which is bloated or slow to load will be penalized in search engine rankings. It is in your best interest to have a fast site even if you don't care about the social and environmental impact of your site.
Operating assumptions
Most articles you may have read on the subject of site optimization tend to be axiomatic. They purport there's such a thing as the One True Way and you'll be cast to eternal damnation if you don't follow it. The irony of the fact that there are as many mutually exclusive axiomatic views as there are people writing articles has apparently eluded these authors.
There is no such thing as the One True Way. Even implying that a small site built by a single person in their spare time can or, worse, should follow the same methodology as a medium-to-large site being built and maintained by a dedicated team of at least a few dozen people is out of touch with reality.
I am writing this article series with the majority of site integrators using Joomla out there, building sites alone or as part of a small team, within time and budget constraints imposed by their clients. Most of you are building very small to medium sites for Small to Medium Businesses or even small “mom and pop” shops. You can't afford to get obsessed over achieving a “perfect score”. That's the almost unattainable target, not the pragmatic expectation for each and every site. Yes, you can achieve a perfect score but if that means that you have a site that's a pain in the rear to build and maintain is that really something positive or did you unwittingly put your name down for a Darwin award?
You should optimize only as much as you can afford to. You have deadlines to meet and, frankly, some of the optimizations might simply take a disproportionate amount of your time for marginal gains. Start simple and only go deeper depending on your client's deadline and budget.
This is the context of this article series. It’s not axiomatic, it’s practical. I am presenting various ways you can optimize real world sites with a reasonable trade–off between full performance gains and maintainability. These are not clean–room approaches which work great in theory but in practice require far more resources than realistically available to most of our readers.
Let’s put this in another way. Yes, you can always create a microservices and CDN backed application if you please. Or use some really advanced techniques which work around a plethora of limitations imposed by the one-size-fits-all approach of using a CMS like Joomla (or WordPress, or Drupal, or...) instead of building your own custom application. But I'm not here to tell you why or how not to use a CMS. I'm here to tell you how you can best use the CMS you have to achieve better results you previously didn’t know how to get close to. These are all techniques I've practiced on my sites and they did work like gangbusters!
The absolutely “obvious”
When you have been using Joomla since it was called Mambo back in 2004, like yours truly, there are some basic truths about how you approach site building that seem fairly obvious. Here’s the thing. Nothing is really “obvious”; it’s all about experience.
In the past I thought that people must be out of their mind for not seeing a number of points which are painfully obvious to me. Eventually I did realize that I have a unique experience of having been into the backends of countless sites and I have collected a unique set of skills over a long career... Sorry, wrong movie. What I mean is that I realized that what is obvious to me may be fairly arcane to someone who's either starting out now or is used to doing things a different way than I have. Truth be told, if I could reach out to myself from 16 years ago I'd probably slap me in the face for doing things I learned the hard way at some later point in time are either nonsensical or undermining me in the long run.
I'll discuss the three most common mistakes I've seen on sites and how to easily fix them. Hey, some of them don't even have to do with Joomla itself!
Hosting
The most common mistake I see is people choosing cheap, shared hosting and then complaining that their Joomla site is slow. Yes, their site is slow but Joomla is not the reason. The hosting you choose for your site is crucial. Don't try to shave pennies here!
Have you ever wondered why a cheap host offers a price in the sub-$3 per month range whereas a good quality host charges five to ten times as much for shared hosting of the same or nominally lower specifications? The difference is that the cheapest host is trying to cram more sites on a single physical server and keeps costs down by using slower CPUs and memory, slower mechanical disk drives and more limited Internet connectivity. All these conspire to make your site appreciably slower to begin with. No amount of tuning can save you when you start with bad hosting.
Think of it like that. You can make a car as aerodynamic as a fighter jet. If the engine it runs on is a single–cylinder, two–stroke engine from a moped it won’t win and land speed records. It will probably be overtaken by someone walking at a brisk pace. The engine of your site is your hosting environment. It dictates the maximum performance you can eke out of it.
Try to strike a balance between ideal performance and your realistic budget. If unsure, choose a mid–range shared hosting provider with good word–of–mouth reputation and possibly re-evaluate after a couple of months with real world traffic. If your client dictates the hosting make sure to have The Talk with them: explain that no matter what you do, their choice of hosting will limit the performance of the site you build.
Pre-built templates
Many people building sites are using a pre-built template with a myriad of options, a generic framework that tries to be everything for everybody, typically combined with dozens of components, plugins and modules to build a site that is really not all that complex if you think about it.
I understand the appeal, having done that myself in the past. You feel empowered to mess around with your site's layout and try out different options until you find what sticks. I'd say that you should do it if you feel like that's your creative process but don't necessarily stick with the generic, pre-built template once you've figured out how you want your site to look. If you feel uncomfortable making your own template, sure, a pre–built is the only way for you but do keep in mind that it will limit you on the performance metrics.
The objective problem is that a generic template is built for flexibility, not speed. In my experience your page load (Time to First Byte - TTFB) can increase by a good 1 to 3 seconds just because of all the unnecessary baggage you're dragging with you using this kind of template. A custom template based off Joomla 4’s Cassiopeia has a negligible impact, in the range of a fraction of a millisecond.
Even if you go halfway and only use a generic template framework you're still dragging along a lot of unnecessary code unless you really know what you're doing. Not to mention that you've installed a substantial amount of PHP and JavaScript code that needs to be regularly maintained for security purposes.
Another problem with pre–built templates and template frameworks is that they tend to load all their CSS and JavaScript in the head of the HTML output which has an adverse impact on your Core Web Vitals, especially the First Contentful Paint. A custom template based off Cassiopeia will be loading these static files deferred, making your site much faster to display.
If you have the skills and time you'll be better off creating your own template. This sounds scary, but it isn't if you're already an experienced Joomla site builder and understand Joomla's basic yet powerful tools, like template overrides. You can use any CSS framework you want and you can start by forking off the default Joomla 4 template, Cassiopeia.
I am not a frontend developer by any means. I managed to very easily take the designed created for my site and “translate” it into a Joomla 4 template based off Cassiopeia without much trouble. Bootstrap 5, built into Joomla and what Cassiopeia is using, is extremely versatile. The only thing you need to understand to make any kind of visual presentation possible — and responsive! — is CSS Flexbox.
Don't overdo it
There’s the age–old adage of "just because you can doesn't mean you should”. In the context of Joomla, just because you can install hundreds of extensions doesn’t mean you should!
With more than 7000 extensions in the Joomla Extensions Directory it's fairly easy to go overboard and install everything under the sun. A plugin for this, a module for that, a page builder in lieu of a simple template override and before you know it you have 300+ third party extensions loading on every page of your site. As you can imagine, this would make any site slow down to a crawl.
Let’s talk modules. My casual observation is that 90% of modules displayed on 90% of the sites I've visited or worked on have no reason of existence. Nobody cares about the weather in your city; if they did, they'd be asking Google, Alexa or Siri instead of visiting your site. Nobody cares about the three dozen buttons, links and banners to content you have on the sidebar. People want intuitive navigation, not a phonebook. Even worse, social media sites have conditioned your site’s visitors into entering "sidebar and banner blindness" mode, i.e. they assume this content is junk they don't need to care about. Modules can serve a true purpose but use them sparingly. Don’t try to “fill up the empty space” with useless modules.
Which brings us to plugins, especially content plugins and system plugins which do full page text search and replace. Content plugins run every time content is displayed on your site. They need to do some sort of initialization and some sort of text replacement. These operations take time. Full page search and replace by system plugins, especially if they use regular expressions, take even more time. Is really a search and replace on every page output by your site a better solution to template overrides, language overrides or spending some time changing content either in the backend or in the database directly?
When you combine excessive abuse of modules and plugins you can end up with a site that needs to make hundreds of database queries and spend a good few precious seconds replacing stuff in the content it took forever to generate. Yeah, this site will be awfully slow. It’s really not Joomla’s fault, it’s just the direct result of the implementation approach you took. I won't say it's necessarily bad but I won't say it's the best way to go either.
If you have a problem that needs solving, using an extension should be your last resort. Start with custom fields, template overrides and language overrides first. If you think the site looks “empty” make quality content, don’t stuff it with useless modules nobody cares about but still make your site slower. The prime directive is KISS: Keep It Stupidly Simple. It's easier said than done and it usually takes a few iterations to get there. Remember to always re-evaluate whether you need an extension and disable or uninstall it when you're no longer using it.
Override instead of adding cruft
Most people approach developing their or their clients’ sites the same way an Android or iPhone user approaches using their device: if I need to do something I need to install something. I call this the There’s An App For That Syndrome or “TAFTS” for short. Sounds like a terminal condition, doesn't it?
People suffering from that syndrome end up using a bazillion of extensions which make the site slow and become a major roadblock in updating Joomla or PHP a few months down the line.
The thing is, you don’t need to add cruft onto your site. Joomla is extremely flexible out of the box. When you want to do something stop and ask yourself: can this be done with just core Joomla features?
Unlike most CMS out there, Joomla allows you to override how it displays anything and everything using language overrides, template / layout overrides and custom fields. Using these simple tools you can create incredibly complex content that's dead easy to manage. After all, Joomla descends from a CMS called Mambo whose motto was “power in simplicity”.
Using nothing but layout overrides and custom fields I created a video tutorials page for my business site, self–hosting the videos (no YouTube / Vimeo embeds). The video categories page you land on is a Joomla category blog view with a simple template override and a sprinkling of custom CSS. When you click on a category you see a list of videos. This is just a category list view with a template override. The length of the video is a custom text field. There are two more custom URL fields pointing to the video file and the poster frame image. These are used to display the upper part of the individual video page (video player). That page is just an article. The article content is the transcript you see further below the page. The transcript has data-timecode attributes which are parsed by the page's JavaScript, itself loaded in the template override, making them clickable links to point to specific points in time in the video player. It's neat and it's all core Joomla. No need for a third party gallery or a dedicated video tutorials component.
I've seen the humble Tags list page becoming a beautiful content area selection panel for a non-profit. I've seen core articles with custom fields define the content in a user friendly manner for a touch-first web application, with zero third party code except the JavaScript touch event handler. I’ve even seen very straightforward template overrides which make the Joomla user profile page look like a professional, high–end service instead of a bunch of thrown–together fields.
Granted, not everything is possible with just the core — you can't reasonably do e-commerce or book appointments with core Joomla, you need a third party extension or service — but extensions are definitely not the first or only choice you have as a site integrator.
By sticking to a well-planned and minimal usage of third party extensions you avoid making the site slower and ensure that it's maintainable in the long term. This is especially important when lesser used extensions drop out of the face of the Earth and you're left with the hard choice of partially reimplementing a site or sticking it out with an out of date version of Joomla. Remember, folks, an ounce of forethought is worth a pound of frantically trying to fix a bad decision when it's already too late.
