Skip to main content
Blog

What actually makes a Joomla website fast?

14 August 2026

A fast website is a pleasure for your visitors and helps you rank higher in search engines. You click on something and the page loads almost instantly.

No spinning icon, no half-loaded page still waiting to appear, and no images causing the whole page to suddenly jump around.

But what actually makes a Joomla website fast?

A fast Joomla website is the result of a combination of good hosting, a fast PHP and database configuration, efficient caching, a lightweight template, as few unnecessary extensions as possible, and optimised images and front-end code. The whole chain needs to work well together.

But often the first answer I hear is: caching.

Caching does indeed help. But a fast Joomla website is much more than just a website with a good cache. Speed is determined by a whole chain of factors: the hosting, PHP, the database, Joomla itself, the extensions used, the template, images and everything the browser ultimately has to download.

You can compare it to a restaurant. A quick waiter helps, but if the kitchen is slow, the ingredients have to be fetched from the storeroom and it takes twenty steps to prepare a single dish, the customer will still have to wait a long time.

With a website, it actually works in exactly the same way.

It starts with the hosting

Every Joomla website runs on a server somewhere. That server forms the foundation. You can configure a Joomla site perfectly, but if the underlying hosting is slow or overloaded, the website will remain sluggish.

Good hosting does not automatically mean that you need the most expensive package. What’s more important is that the server is properly configured for modern websites.

For Joomla websites, I usually work with a Virtual Private Server (VPS). This gives me much more control over the configuration and performance than with traditional shared hosting. For example, I can optimise the PHP version, caching, database settings and web server for Joomla myself.

On my VPSs, I use, amongst other things, fast web servers such as Nginx and OpenLiteSpeed. In my experience, these deliver better performance than a standard Apache configuration that isn’t specifically optimised for speed. That doesn’t mean, however, that every Joomla site needs a VPS. For a smaller website, good shared hosting can be perfectly adequate.

Consider, for example, a recent version of PHP, sufficient memory, fast storage and a well-configured database server. PHP is the programming language in which Joomla is largely written. PHP has to get to work on virtually every page a visitor requests. The more efficiently this happens, the faster Joomla can generate a page.

The database must also play its part

A Joomla website stores a great deal of information in a database. Articles, menu items, users, tags, settings and extension data are all stored there. When someone visits a page, Joomla retrieves some of that information.

A few database queries are no problem. However, some extensions or modules execute a large number of database queries, some of which can also be relatively resource-intensive. This can take up a lot of time without you even realising it.

That is why it is important to look not only at Joomla itself, but also at what extensions are doing behind the scenes. An extension that adds fantastic functionality but noticeably slows down every page will ultimately affect the visitor experience as well.

This is where caching comes in

Caching ensures that Joomla does not have to repeat the same work every time.

Suppose a hundred visitors view the same page. Without caching, Joomla may have to execute PHP code a hundred times, retrieve information from the database and generate a complete HTML page from it. With caching, a previously generated result can be temporarily stored. The next visitor will then receive the already available result more quickly. That can make a huge difference.

Joomla itself offers various caching options, and the web server or an intermediary service can also temporarily store pages.

But caching is no panacea. If a page takes five seconds to load without caching, I also want to know why that page takes five seconds. Caching over an underlying problem makes the problem less visible, but does not resolve the cause.

Your Joomla template plays a major role

Once Joomla has finished gathering information, the browser still has to turn it into a website.

That’s where the template comes into play. A template doesn’t just determine how a website looks. It often also determines how much CSS, JavaScript, fonts and other files are loaded.

A visually appealing template can therefore become quite heavy. That needn’t be a problem, as long as the necessary files are loaded efficiently. But sometimes scripts and stylesheets are loaded on every page even though they aren’t needed there at all. For example, a slideshow script doesn’t need to be loaded on a page without a slideshow. Anything the browser doesn’t have to download and process saves time.

I build a lot of Joomla websites myself using YOOtheme Pro. A key reason for this is performance. The template/framework can deliver a fast front-end, and a great deal of functionality is already built into the system itself.

As a result, I need fewer separate Joomla extensions for all sorts of features. That doesn’t automatically make a website faster, but fewer extensions usually also mean less code, less maintenance and fewer places where performance issues can arise.

Extensions are handy, but they aren’t free

One of Joomla’s strengths is its wide range of extensions. With just a few clicks, you can add forms, online shops, calendars, sliders and all sorts of other functionality.

But every extension also adds code. Some plugins run on virtually every page, even if their functionality isn’t needed on that page at all. If, over the years, you keep installing new extensions without clearing out the old ones, a website can become increasingly sluggish without you even realising it.

That’s why, when performance issues arise, I always ask a simple question:
Do we actually still use this?

Disabling an unused module or removing an unnecessary plugin can sometimes yield better results than all sorts of complicated optimisations. 

‘Stick to the core’

When building a new Joomla website, I also try to keep the number of extensions to a minimum. My motto here is “stick to the core”: make use of what Joomla already offers as standard before installing an extra extension. For example, I make extensive use of Joomla’s standard Custom Fields. These allow you to build a surprising amount of functionality without having to install a separate extension for every component. In combination with YOOtheme Pro, I can use these fields directly in dynamic layouts and pages.

If I do need specific functionality that Joomla doesn’t offer by default, I prefer to program a small custom plugin that does exactly what’s required. No extensive extension with dozens of features I don’t use, and no heavy libraries if they aren’t necessary.

This way, I keep a Joomla website not only fast, but also clear and maintainable. Because when it comes to performance, the rule is often: the less unnecessary code, the better.

Images are often the biggest culprit

So far, we’ve mainly looked at what happens on the server. But on many websites, the bulk of the page isn’t in Joomla or PHP.

It’s in the images.

A photo taken directly from a modern mobile phone can be several megabytes in size. If such a photo is ultimately only displayed at 600 pixels wide on the website, you’re making your visitors download far more than is necessary. This is particularly a waste on a mobile phone.

A good image therefore has the correct dimensions and is saved in an efficient format, such as WebP or AVIF

Furthermore, images that appear much further down a page do not need to be loaded straight away. The browser can wait until the visitor scrolls closer to them. This is known as lazy loading.

A single, well-optimised large image can sometimes yield greater speed gains than spending hours tweaking the server.

The browser has to work hard too

Once the server has sent the page, the job isn’t done yet. The visitor’s browser has to read HTML, process stylesheets, execute JavaScript, download fonts and display images. That’s why a website with a lightning-fast server can still feel slow.

Consider, for example:

  • large JavaScript files;
  • lots of external fonts;
  • scripts from advertising or marketing services;
  • videos that load immediately;
  • external widgets;
  • tracking software;
  • large images.

All these elements compete for the browser’s attention.

You’ll notice this particularly on an older phone or with a slower internet connection.

And then there’s HTTP caching

Not everything needs to be fetched from the server again on every visit.

Files such as a logo, stylesheet or JavaScript file do not usually change every minute. The browser can therefore cache such files temporarily. When you visit the next page, the file does not need to be downloaded again.

A web server, CDN or reverse proxy can also temporarily store entire files or pages closer to the visitor. This is particularly useful when a website has visitors from different countries.

After all, the fastest request is often the one that the original Joomla server does not have to process at all.

A fast website is therefore the sum of its parts

There is no magic button that will suddenly make every Joomla website fast. It is the sum of its parts.

Good hosting provides a solid foundation. A recent version of PHP runs Joomla efficiently. A well-configured database delivers the required information quickly. Joomla caching prevents duplication of effort. A well-designed template keeps the front end organised. Extensions should only do what is absolutely necessary. Images should not be larger than necessary. And browser and HTTP caching prevent unnecessary downloads.

The interesting thing is that you usually don’t have to tackle everything at once. The trick is to first discover where the delay actually lies.

Because if a four-megabyte image is the problem, there’s little point in spending hours optimising the database. And if an extension is running hundreds of database queries, reducing the size of the logo will make little difference.

Measure first, then improve

So when I investigate a slow Joomla website, I don’t immediately start by installing a caching plugin or tweaking all sorts of settings. I start by measuring.

First, I want to know where the delay is occurring. Is the server responding slowly? Does Joomla take a long time to build the page? Are there a lot of database queries? Are huge images being loaded? Or is the page generated quickly, but does the browser then have to process a mountain of JavaScript?

In practice, for example, I come across Joomla websites where caching is suggested as the first solution, whilst ultimately a single resource-intensive extension or a few images that are far too large turn out to be the real cause. You can then optimise the caching even further, but that doesn’t address the actual problem.

Only once I know where the bottleneck is do I start optimising. I then measure again to check whether the change has actually made a difference.

Ultimately, that is perhaps the most important secret to a fast Joomla website:
not optimising as much as possible, but optimising the right things.

Caching is definitely part of that. But true speed only comes when Joomla, PHP, the database, hosting and the front-end work well together. That’s why, when optimising a Joomla website, I always look at the whole chain, and not just at a single setting or technique.

Peter Martin
Peter Martin
Joomla Specialist

Peter is a Joomla specialist en a Linux admin for fast, secure and scalable websites..

Recent articles

Correspondence

db8 Website Support
Galiciestraat 35
6663 NR Lent
The Netherlands

+31 85 301 48 28
support at db8 dot nl
+31 6 44 214 500 (urgent)

Nijmegen Office

NYMA makersplaats, Unit 69
Winselingseweg 16
6541 AK Nijmegen
Netherlands

By appointment
Monday to Friday
09:00 - 17:00 (5pm)
(Time zone: Central European Time)

Acquisition is
not appreciated

© db8.nl. All rights reserved.