Joomla Speed & Performance

Having a fast Joomla website with excellent performance is a key factor for your SEO efforts. Slow sites may not necessarily make your SEO rankings drop immediately, but speed is an actual ranking factor (see this article on searchengineland.com). More importantly, if a visitor tries to access your site and it takes more than a few seconds to load the site, he might leave the site before it loads. This is registered as a bounce by Google and a low bounce rate may harm your rankings. A general rule of thumb is to keep the time needed to load your site under 2 seconds, but preferably faster. And you can definitely achieve this with your Joomla site. Especially Joomla 4 has become even faster than Joomla 3, out of the box. But there is a lot you can do to make it even faster, let's discover the options:

Web hosting

Webhosting is the cornerstone of your website's performance. Choosing the right host can save you many headaches. So, what are the requirements for your hosting provider:

• First of all, do they support Joomla, and do they know the specifics of the CMS? 
• Is their server software up to date and compatible with the latest Joomla versions? Software to look at are Apache, IIS, PHP, and MySQL: are they up to date?
• Especially make sure they support the latest PHP versions. Also, you should be allowed to easily switch between PHP versions, without having to call the host.
• Do they offer advanced features like Memcache, Varnish, SPDY, HTTP2 technology, Let's Encrypt SSL integration, etcetera. Even if you do not yet use these techniques, being able to upgrade easily is a big plus instead of then finding out your host does not support it and having to move.
• Do they allow for easy upgrading or downgrading of your hosting package?
• Check their pricing!
• Finally, check user reviews for the host you have in mind

Shared or dedicated hosting

Now that you have chosen a hosting company, you should also look at which server package you select. For really high-traffic sites or sites that are important, choosing a dedicated server package will probably be your choice. But also shared servers can still offer great performance, even if they have some downsides. When you are on a shared server, you share the same IP (and resources) with other sites on the server. Especially if you share the same IP as an insecure or malicious site, this could potentially be bad for your online reputation, and in some cases, even for your ranking.
This also depends on how close your host monitors their sites. For 80-90% of websites, being on a shared server should really not be an issue.

Web hosting companies

Happily, there are quite a few companies that offer excellent hosting and comply with the requirements mentioned here. Personally, I only have experience with Siteground.com and they offer great performance. I used to have some issues in the past, but currently, I am very happy with their performance and also their support. But there are plenty more companies. For Siteground, I have written a full review.

Server and software updates

Always keep your server software, Joomla core, and Joomla extensions up to date. New software often incorporates performance updates, and you don't want to miss out on these. I already mentioned that Joomla 4 is faster than Joomla 3. PHP 8 is faster than PHP 7 or lower, etcetera. Of course, updating stuff should be a no-brainer for any Joomla admin, but I often see old software out in the wild...

Limit Joomla extensions

With Joomla beginners there often is a tendency to install a lot of extensions, especially front-end extensions like galleries, social media feeds, video plugins, etc., because they look so nice. Especially extensions connecting to external sources, like Facebook, Twitter, Picasa, Flickr, etc can seriously extend the load time of a page because the external connection takes additional time. However, every additional extension will always take up some time. Well-programmed extensions will take a minimal amount of time to load, so it also pays to check only extensions of well-known providers. Of course, in most sites you will have to use some extensions, you can hardly build a ticket-selling website without an event manager, but whether you need a Twitter feed on all your pages is worth considering. Maybe you just need it on your contact page, which will free up the homepage.

Sliders and carousels should be avoided as much as possible. Though web designers and their customers often find these very attractive, actual users that visit the website often ignore them, or even treat them as ads to be blocked (banner blindness). Usability tests have proven that they are often very ineffective and that no more than 1% of users ever click on a link or feature in the slider. On top of that, they usually require multiple (large) images and Javascript files or libraries.

Make sure you check your Joomla template if you need to optimize your website speed. Templates with a lot of stylesheets, javascript files, and javascript libraries slow down your website speed and should be avoided. Some templates offer optimization from within the template settings, like CSS compression, optional loading of Bootstrap, etc. Personally, I mainly use Yootheme templates, as they are pretty lightweight compared to other providers.

Activate G-Zip

Now that our basic setup is top-notch, the next step is to investigate the performance options within Joomla. One of the first ones you should encounter is the option to activate G-Zip. This activates a built-in compression mechanism for your Joomla assets and HTML. You can access the options from within the Global Configuration settings, on the Server tab:

It is just a small improvement, but it's one of the many little steps you can take. And there are hardly any disadvantages to using it, so I advise you to simply activate it.

Joomla caching options

Caching offers users a stored view of a web page so that the server doesn't have to perform interactions with the database.  This can save a lot of processing time, resulting in much faster page loads. Where G-zip only offers small gains, caching can result in massive gains. However, it can also result in massive issues if not set up correctly!

Joomla and almost all other CMSs are PHP / MySQL based, which means that in order to generate the necessary HTML needed to show the user a web page, a lot of processing has to be done first, first pulling the article data from the database, the same for the modules, and then composing this into one HTML page. This is why completely static HTML sites are usually faster. Caching tries to overcome this by re-using the earlier generated HTML from Joomla.

This usually speeds up the load time of a webpage, but the disadvantage could also be that a user looks at a stored view, while the actual page has been changed in the meantime. Whether or not this is a problem depends on the site. When you are busy developing a site and making a lot of changes, it is usually best to leave caching switched off. Also, there could be functionality that does not work well with caching, like some captchas, forms, and webshop extensions (Virtuemart, Hikashop, etc). With additional configuration, this can sometimes be overcome.

For this reason, a default Joomla installation ships with caching switched off. The Joomla core offers a number of possibilities to use caching, in multiple locations: per Component, per Module, or per Page. The stored views for this are actually stored in the filesystem, in the /cache/ folder, as you can see when caching is switched on. You see a number of folders and files sitting there, which are actual HTML files that are offered directly to the user.

You can see com_* for component views, mod_* for module views, and page for full-page views. When you examine the files in these folders, you can actually recognize the pre-generated HTML content. Note that you cannot just access these files directly, they need to be served by Joomla. When you actually want to use caching, you can activate it on multiple levels. Let's see how they work:

First, go to Global Configuration - System tab - Cache Settings. There are a number of settings and options here:

First, you will set a global setting. Joomla offers three possibilities to use caching here:

0 - Off
1- Conservative caching
2- Progressive caching

Progressive caching can cause unexpected issues in rare cases, so it is advised to use the conservative option. This turns on caching for the component and modules. It also allows you to override the global cache setting on a per module basis while progressive caching does not allow this, as it stores a cache view of the combined modules.

The Cache Handler can only be set to "File". Joomla actually offers more options (like mem-cache for database caching, scroll down for more information), but it takes advanced users to enable this, with sometimes additional plugins and set-up.

What is worth looking at is Cache Time. The default is 15 minutes, but for sites that are not updated often, you could set this (much) higher.

Joomla also offers Platform specific caching. When you leave caching disabled, the option is hidden, but if you enable caching, the option appears, as in the screenshot above. Use this option when you offer device-specific content: maybe you make some modules only load on non-mobile devices. Then device-specific caching prevents caching issues between devices like mobile users getting a cached version of a desktop view. Note that most users don't need this option, also when you are simply using CSS to hide things with classes like hidden-phone.

On a per-module basis, you can override the Global setting for cache (if you have set global cache to conservative). You can only switch it off when on a global level it is switched off, not the other way around. 

System - Page Cache plugin

A bit hidden inside the plugins, there is also a separate caching option. The System - Page Cache plugin switches on caching for the whole page being accessed. This can speed up your site considerably, as it basically turns your site into a static HTML site. However, especially for pages that need interaction with the user (like a contact form), or non-static content, issues are known, so test carefully. Also, the stored views can increase the size of your hosting-account. Best use is for simple, small, static sites, but many sites are like this: on Joomlaseo.com the plugin works perfectly. Read this post by Yireo to read about some of the disadvantages.

Activation is easy: in the Plugin Manager, look up the "System - Cache" plugin and enable it. Optionally you can switch on the "Use browser caching" option, but it is only useful for sites where users often return to a page that they already accessed within a browsing session and it can also cause issues, so best is to leave it switched off.

Cache cleaning

Periodically, you may have to clean your cache. An example could be when you are editing an article in the backend and you want to see the changes on the front end. If you have set your cache waiting time to 15 minutes, this means that you would have to wait 15 minutes to see the changes. To clean the cache before that, you can go to System >> Clear Cache. Select all entries shown and then click the Delete button. Now you can see your changes. 

However, all this is very tedious if you have to do it multiple times. A very clever solution has been created by Regularlabs, with the Cache Cleaner plugin. It allows you to clear cache from within every part of the backend, even from within an article you are editing. Even more, you can set it to clean automatically every time you perform a save action, or after a set timeframe, like every hour or so. Finally, in the Pro-version, it is even capable of clearing 3rd-party cache, like your CDN, or Siteground cache!  

Reduce image size 

When your website uses many images, it is important that they are optimized and as light as possible. Images often form the largest proportion of the weight in kB of your loaded resources. The biggest problem is often inexperienced users that upload images that are far too big and then simply make them fit in the editor window. This only reduces the dimensions with which the images are being viewed, but actually, the page loads a really big image. You need to prevent users from actually uploading those large images. Also, you should consider how your images are loaded for mobile devices! But simply reducing the pixel dimensions in itself is not enough, there is much more you should do.

Make sure to choose the correct file format. Usually, you will choose between the following 3 formats:

• GIF: Small in size, low quality, only use for small images, icons, or images with uniform, basic colors.
• JPG/JPEG: Larger in size, no transparency, but the only way to go to show photographs. Within this format, you also have the option to use either Progressive JPG or Baseline (can be set in Save for Web in Photoshop). Progressive JPG immediately shows a blurry preview while loading, getting sharper as the whole image loads, while baseline images are the ones that start showing from the top, first showing the top edge, and slowly displaying the whole image. Progressive is the advised option by Webpagetest.org and Google PageSpeed. However, some say it also takes more processing power, which could be bad for loading the image on mobile, so this is not an absolute answer. Personally, I try to follow everything Google tells me to do, choosing progressive.
• PNG: Choose this for smaller images, logos, etc, or anything that needs transparency.

An even larger contribution is the image quality when saving for the web. Going down from 100% to 60% can dramatically reduce file size, especially for smaller images while visually, they still look perfect. but this is only the first step!

Use correctly sized images

You should make sure that you always use images with the exact dimensions needed for displaying them. It is possible to 'resize' images with the editor, but this only changes the display properties, it does not actually resize the image, you just display it smaller. This does not reduce image size. Some plugins and editors do allow for actual resizing, you should make use of those, or simply resize them in Photoshop before uploading. A very useful option is to use the JCE editor, combined with the Image Manager Extended. It allows you to set a default resize option in the profile configuration settings. With this option enabled, the images are resized while they are uploaded to the site. The JCE editor even contains a really nice feature that can save you a lot of kB's. It is hidden away deep in the parameters, but it can reduce your images a lot. It actually removes the EXIF data from images while uploading. This can save more than 30% in size, and display quality is not affected. The option is available in all JCE versions. To activate it, go to Editor Profiles >> Editor Parameters >> Filesystem and switch on the Remove Image EXIF data parameter:

While you are there, you can also change the Upload Quality, saving you some more kB's. 

Lazy load images

Apart from all further optimizations discussed, you can also lazy-load images. Implementing this technique excludes loading of images "below the fold". Images will only be loaded when they are scrolled into the viewport. A placeholder div-element is created until the image enters the viewport. Note that to prevent problems with shifting content, Google advises always configuring the width and height attributes of images! The technique uses simple Javascript to perform the calculations. Especially for sites heavy with images, this can drastically reduce your bandwidth usage. Note that some template providers, like Yootheme offer this option in the configuration, but there are also extensions that can take care of this. Note that currently, most browsers support lazy-loading without any Javascript if you supply the loading attribute, like this:

 <img src="/image.png" loading="lazy" alt="…" width="200" height="200"> 

Note that you should make sure not to lazy-load images above the fold!

Responsive images

Most responsive websites use responsive behavior for images by simply reducing their dimensions so that they fit in their container, often by setting a max-width value in CSS. A more appropriate solution would be to load a separate, smaller image for smaller screen resolutions. This is where the responsive images technique comes in. Currently, you can use 2 methods:

1: srcset and sizes attributes in <img>:

<img src="/small.jpg" srcset="/large.jpg 1024w, /medium.jpg 640w, /small.jpg 320w"  sizes="(min-width: 36em) 33.3vw, 100vw"  />

2: The <picture element>:

<picture>
    <source media="(min-width: 40em)" srcset="/big.jpg 1x, /big-hd.jpg 2x">
    <source srcset="/small.jpg 1x, /small-hd.jpg 2x">
    <img src="/fallback.jpg" alt="">
</picture>

 As you see, the <picture> element has a fall-back solution for unsupported browsers. Also, check  responsiveimages.org for more information about this. Note that some template providers, like Yootheme, offer this feature by default. The template creates snapshots in various sizes automatically for you.

Advanced image formats

Finally, there are image formats that are much more advanced than the classical formats JPG, PNG, or GIF. An example is WebP, which is widely supported in most browsers. Your template provider may already support converting your images automatically. AVIF is an even lighter format, though it is not supported as widely as WebP. Probably more formats will emerge, hard to say what will become the future standard...

If executed correctly, the sum of your images may be cut in half or even more, which is a huge performance gain!

Optimize CSS and Javascript

After images, CSS and Javascript are often the largest reason websites can be slow. Especially large and complicated Joomla templates can use many CSS and Javascript files. Loading all these resources takes time and raises the number of HTTP requests. Minimizing these requests in both size and number can be a huge timesaver for your website speed, so you need to do something about that. 

First of all, you should prevent unused resources from loading. Your site will probably load some resources that you do not actually use. Joomla by default loads a CSS file to style the system errors, but if you set error reporting to Nopne (as you should), this styling will never be used. Similarly, it loads a web font file for Fontawesome, even if your template has another icon font in use.  Preventing the loading of these resources unfortunately requires you to use an optimization extension, unless you code your own templates and know how to unset the loading of these files.

Combining separate CSS and JS files into just one CSS file and one JS file can save a lot of HTTP-requests and it is sometimes still an advised practice, but note that browsers are currently capable of loading resources in paralel, so this is not needed anymore.

However, the size of the individual files is important. Minimizing files can be very useful. Minimizing means that all whitespace is removed, changing a structured code block into an unreadable block of code. For browsers, this makes no difference, they do not need whitespace.

Deferring Javascript or loading them asynchronously is a technique that is especially useful for pages that are heavy with Javascript, but also smaller pages can benefit. Deferring means that "the script is executed when the page has finished parsing" (see w3schools), meaning that loading of the page is not held until the script is executed. It is used for external javascript, in-line Javascript will still execute in order of loading. Technically, this means that the "defer" attribute is added to the script:

<script src="/js/script.js" defer>......</script>

This is a very useful technique, and can save a lot of loading time. The downside is that it sometimes breaks functionality, as some functions require immediate execution of the script to function well. Make sure you test!

Optimization plugins

The techniques described so far are not easy to implement, but happily, we have some clever developers who have built plugins that can help us do so. Perfect examples of extensions for this purpose are JCH-Optimize, and Jspeed. They offer many optimizations, like combining and compressing individual CSS and Javascript files. They can also defer or async Javascript, meaning the Javascript is only executed once the page has finished loading. Also, they offer image optimization techniques, CDN implementation, etcetera:

Whether the site still fully works as desired needs to be tested, but usually, it does. If it doesn't, play with the parameters, this often solves things. Make sure to only use one of these extensions at the same time! Note that your template may also include some of the mentioned optimizations.

Leverage browser caching

Leveraging browser caching is one of the easiest methods to gain a significant performance increase for any site, regardless of the CMS or system, so make sure you use it. Browser caching helps to speed up your website (Joomla or not) by caching resources/files in your browser. Configuration is fully done in the .htaccess system file, outside the Joomla configuration. Basically what you do is the following: you specify an expiry limit in minutes/days/weeks for specific file types, like images, CSS or Javascript. As long as the expiry has not passed, the resources will not be downloaded again, but the previously downloaded version will be used. 

Of course, there is a small risk that resources that have been changed in the meantime will not be picked up, but for most sites, this should not be a problem. Only if you are developing a site and changing your CSS files often you should not use it yet. You can specify the expiry per file type, so for resources that you expect to change often, you set a short limit, while for non-changing content you set it (much) longer. Typically HTML should expire very short in order to show updated content, while your javascript files may hardly change, except when you update it on purpose, or with major upgrades.

In order to activate the feature, you have to set expiry rules in your .htaccess file. In the case of Joomla, you need to make sure you have renamed htaccess.txt to .htaccess, and switch on URL-Rewriting in your Global Configuration. In the .htaccess file, we will first set some more rules that I will first explain shortly:

• ETag: Inform the browser that the image has already been downloaded and should not be reloaded
• Expires headers: like ETag but more specific per file types
• AddOutputFilterByType DEFLATE: minifies HTML by removing blanks ()

The last rule does not actually control the caching of resources, but it takes care of compression for specified file types. Then, we are going to specify our rules (expire headers). There are a lot of ways you can specify your rules, depending on what file types you use on your site, and how long the expiry should be. A simple example to start off with could be the following:

<IfModule mod_expires.c>
  FileETag MTime Size
  AddOutputFilterByType DEFLATE text/plain text/html text/xml text/css application/xml application/xhtml+xml application/rss+xml application/javascript application/x-javascript
  ExpiresActive On
  ExpiresDefault "access plus 1 seconds"
  ExpiresByType text/html "access plus 600 seconds"
  ExpiresByType application/xhtml+xml "access plus 600 seconds"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType text/javascript "access plus 1 month "
  ExpiresByType application/javascript "access plus 1 month"
  ExpiresByType application/x-javascript "access plus 1 month"
  ExpiresByType image/x-icon "access plus 1 year"
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType image/gif "access plus 1 year"
</IfModule>

For every file type you specify an expire header to specify how long you want to keep re-using it. In this simple example, you see that Javascript and CSS are kept for 1 month and images for one year. It depends on your site whether these rules work for you. If you have frequently changing images, maybe you need a lifespan of 1 month instead of one year, etcetera.

You may need to further enhance the code and add expire headers for other file types you use, like .mpeg, .woff, etc., or change the expiry time if it does not suit your needs.

Note that your server needs to support the mod_expires feature in Apache. For safety, the code is wrapped in an if-statement. If your host does not support mod_expires, your site will crash. My own localhost environment on my PC also does not support it, so it helps me not to have issues when I restore the site locally for testing purposes. With the if-statement in place, the code will simply not execute if no support is available.

For a more advanced example of a .htaccess file (including a lot of security rules), see the docs.joomla.org site.

Before you make any changes, first make a backup of your .htaccess file, and make sure to test thoroughly after activating the change. Check before and after to see if the change made a difference to the speed of your Joomla website.

Some extensions can take care of the optimization for you. JCH-Optimize does, and also Akeeba AdminTools can do this in the .htaccess maker.

Optimize for mobile devices

Especially with more and more users viewing your Joomla website on mobile devices, you need to make sure it loads fast on those devices as well. While most desktop users in developed countries will have a broadband connection, this might not always be true for users on the go, with a 3G connection. Even if you use a responsive template, the way the site is viewed adapts to the screen size, but the resources that are loaded are the same as for the desktop user. We already discussed how images should be optimized for mobile devices, but for advanced users, we have some more options. Note that you mostly need paid extensions to achieve this.

Kubik-Rubic extensions by Victor Vogel offers an extension to add content based on device detection, DSC - Device Specific Content. It allows you to add content based on tags, distinguishing between Desktop, Tablet, and Mobile.

Another possibility and my personal favorite, is the use of the Regularlabs extension Advanced Module Manager, which also works based on user-agent. It allows you to specify many parameters, including whether or not to load modules for mobile browsers:

If you have caching switched on, you can sometimes have issues if you use these extensions: if the first visitor after clearing the cache is a desktop user, this view may be stored in the cache for any user following, including mobile. For this reason, Joomla introduced the mechanism of Platform Specific Cache in your Global Configuration. This feature was developed specifically for use cases like these.

CDN (Content Delivery Network)

A Content Delivery Network is a network of servers around the world that can be used to offer resources to users without having to pull them from the source server which is limited to one location. This makes the use of a CDN especially useful for websites that operate globally, like the Joomlaseo.com website, which attracts users from all continents. Especially if you suspect your site is often accessed from developing countries, a CDN becomes even more efficient, as the infrastructure is often less advanced. Even if you think your website is very fast, it may not be the case in say, Gambia.

But even sites that only target a specific country will always have users that travel and want to access the site from abroad. Also, countries like the USA, Russia or China are too large to be served efficiently from just one location. So, there are enough reasons to implement a CDN, especially as implementing one does not have to be very difficult or expensive.

Technically (in the case of a pull-CDN), the CDN fetches the files of your website and distributes them to data centers all over the world. Based on how you set it up, the static files will be served from the CDN, which will usually be:

• Images
• CSS files
• Javascript files
• Webfonts
• etcetera

Anything non-static, like the ever-changing content of your articles, like the HTML itself, should not be fetched from the CDN. Often, 75% of the size of your website will now be pulled from the nearest server of your CDN provider.

When you implement a CDN on your website, you basically configure the static content to be pulled from the CDN. Let's look at an example for an image. Without a CDN the image would be fetched as follows:

<img src="/images/seo-joomla.jpg." />

After the CDN is activated this will be:

<img src="/https://cdn-url-xxxxx.netdna-cdn.com/images/seo-joomla.jpg" />

You clearly see the difference: instead of the relative URL that would pull the image from the website's domain, it is pre-pended with the domain of the Content Delivery Network. For your CSS and Javascript files it does not matter too much that these URLs are a bit long and funny, but with some more setup, you can make the resources lad from your own subdomain, like cdn.joomlaseo.com or something like that. You should configure a CNAME record on your domain (with your own web host), and your files then seem hosted on a subdomain of your own site instead of directly on the CDN. If this sounds complicated, just forget it, usually you should be fine without any issues. 

If you want to use a CDN within Joomla, usually you will have to go through 2 major steps:

1. Sign up with a CDN service, like KeyCDN. There are many, some expensive, some cheap or even free, or services that only bill used bandwidth, which makes them nice for smaller sites.
2. Configure the CDN in Joomla, usually using an extension, like CDN for Joomla by Regularlabs.

As an alternative, you can choose a web host that offers CDN functionality through their Cpanel. Siteground.com is an example, where you can switch on the CDN without any configuration in Joomla.

Note that the described setup applies to pull-CDNs. Another type of configuration is a service like Cloudflare, which basically takes over the DNS of your site and routes all traffic through their servers.

Verify your speed

Finally, after all your work, the first and most important thing to do is to check that your site still works as desired, as some of the optimization techniques can cause issues in rare cases. But the final action for you to do is to verify the performance of your site! Even if your site loads fast in your office with broadband wifi, this may not be the case in the real world for your customers, shopping from their phone on a 3G connection. To check this, use an online service to measure your performance. Examples are GT Metrix and Pingdom Tools, but the best one to use is Google's own tool, Pagespeed Insights. Just paste your URL and check the results:

Make sure to check the Mobile tab first, as usual, most of your users will be on mobile devices! Lower on the page, Google will tell you what can be improved. Note that you can also run the test from within your developer tools in Chrome, using the Lighthouse tab.

So, hopefully, you find that your site is very fast now. But make sure to check back every now and then!