In the second part of this series I described how to unlock a base level of performance out of your Joomla site with a few, simple changes. Today we're diving deeper into static media: JavaScript, CSS and image files. These changes are more involved but can turn a junker of a slow site into a decently performing one. Arguably, not all of these changes make sense for all sites but the performance benefits you get are substantial.
A large part of your site comes in the form of static media files: CSS, JavaScript, images and possible audio and video as well. We tend not to think much about them, considering them secondary to our content, but they typically make up the majority of the data transferred from our site's server to the user's device when they are visiting a page. Further to that, parsing large CSS and JavaScript files or decoding large images freezes up the main browser thread which, in simple terms, means that the browser cannot do any work for rendering the page (it can only download more data in the background). Moreover, the more CSS, JavaScript and image files you have the longer it takes for them to all be loaded which means that the browser has to stop rendering the page and recalculate everything from scratch every time one of these files finishes loading up. This can make the page appear slower or cause other rendering artefacts such as content jumping around the screen (that's called "Layout Shift" in the browser jargon).
Optimise your images
If you have an image-heavy site, like a blog or a news site, the biggest part of your page content transfer is the images. You are probably used to just taking an image, upload it with Joomla's Media Manager, maybe resize or crop it a bit — Joomla 4's Media Manager can now do that! — and call it a day. Good for you, but your images are very likely unoptimised and larger (in Kilobytes, not necessarily dimensions) than they should be.
Maybe you are vaguely or keenly aware of tools such as pngcrush and mozjpeg. If you are comfortable with the command line do use them to optimise your images.
Even easier, there's a free tool called ImageOptim for Windows, macOS and Linux which can run several of these tools against your images and choose the smallest file. It's dead simple. Drag and drop your image folder onto the tool. Wait until it's done. Your images are replaced with their optimised versions. Obviously this should first be done on a local copy of your site. If unsure, keep a copy of your original images because ImageOptim overwrites your images with the optimised versions.
Make your images adaptive
You already know that your site will be displayed in devices with different screen sizes: sub-5" budget-friendly Android phones, 6" mainstream smartphones, 7"+ phablets or small tablets, 10"-11" tablets, 13"-15" laptops and massive 23"+ desktop monitors. You have already taken that into account by making your site responsive which means that your content scales and your design contorts itself to the interaction modes that are most appropriate for the screen size your site is rendering in.
But what about your images?
When your target devices range from a 380px wide budget phone to a 5120px wide desktop the same image file is not appropriate for all sizes. If you optimise for the small screen the image will look blurry and pixelated on the big screen. If you optimise for the big screen then most of your visitors are downloading an unnecessarily big file to display a much smaller image. Optimising for the most common device size in your audience is the worst of both worlds: small devices download a big file and big screens show a blurry photo.
If you also start taking into account HiDPI devices with pixel densities that are 2x, 3x or 4x the standard screen density (the standard is 96 pixels per inch) you have quite the puzzle to solve. Do you go for a reasonably small file which will display badly on a lot of devices or a massive file which does display great in all devices but is in the ballpark of a couple Megabytes big?
Luckily, you do NOT have to choose. Browsers have long supported adaptive images. In short, using the PICTURE element with the appropriate media queries you can tell the browser to automatically select the right image file for the display (resolution and DPI) your site is being rendered on. If the display size changes, e.g. the user rotated their device from portrait to landscape or resized their browser window on the desktop, the browser will smartly figure out what to do. If it has a large enough image it will scale it down. If it doesn't and you have hinted in your PICTURE element that a more appropriate image file is available for the required dimensions it will load that instead. While the bigger image is being loaded the smaller will appear scaled so from your user's perspective there's a bit of blur in the images that goes away in a short period of time.
Another magic thing you can do with the PICTURE element is have the browser select the most appropriate file format it supports. Most images on the web are JPG or PNG. These are legacy image formats, dating back to the 1990s or even earlier. Most modern browsers also support WEBP, a much more efficient image file format which results in much smaller files while supporting transparency. From your perspective as a site builder it's like PNG on steroids. Unfortunately, you can't just go ahead and convert everything to WEBP because older browser versions (and all versions of Safari) do not support WEBP at all.
By now you might be clutching your head in despair. What was simply uploading a single image file and putting an IMG tag in your content has now become a puzzle which require you to create various different image sizes and image types. This is difficult for you, the site integrator, and outright impossible for your clients.
Luckily, there are third party Joomla extensions which can handle that for you. I have used XT Adaptive Images Pro in the past. There's also Econa and possibly others — you can take a deep dive into the Joomla Extensions Directory where there's an extension for every need and budget.
Another option is to go ahead with layout overrides and a helper which automatically creates responsive versions of your images. This is the code I contributed to the Lightning template by Charlie Lodder. If making custom templates is your jam you can easily adapt these layout overrides and the helper class for use in your own template.
Vector illustrations
Another point to be made about images is that illustrations (as opposed to photographs) typically start their life as a vector file in something like Adobe Illustrator or Affinity Designer. What we usually see is that these are converted to transparent PNG files before being used on a site. This is the least efficient way to go about it.
Browsers have long supported scalable vector graphics (SVG) files, small text files which describe vector graphics. They tend to be much smaller than file formats optimised for photography (JPG, PNG and even WEBP), they are far more compressible due to them being plain text and can be scaled to any size from tiny to humongous on any screen resolution without losing crispness.
While in Joomla 3 there was a conspicuous absence of any SVG support — or even the possibility to add it without using third party extensions — this is perfectly possible in Joomla 4 as long as you manually enable it. Go to Content, Media and click on Options. Change the Legal Image Extensions (File Types) to include SVG i.e. change it to:
bmp,gif,jpg,png,svg
If you have enabled Restrict Uploads (you should!) also change the Allowed Extensions to include svg i.e.:
bmp,gif,jpg,jpeg,png,webp,ico,mp3,mp4,odg,odp,ods,odt,pdf,png,ppt,txt,xcf,xls,csv,svg
If you have enabled Check MIME Types you will also need to add image/svg+xml to Legal MIME Types, i.e.:
image/jpeg,image/gif,image/png,image/bmp,application/msword,application/excel,application/pdf,application/powerpoint,text/plain,application/x-zip,image/svg+xml
Click on Save & Close. Now Joomla allows you to upload SVG files and to use them wherever an image is allowed to be inserted.
One final note of caution: do not try to use SVG files in elements which expect to get their size from the content (SVG files do not have an intrinsic fixed width and height for all the browser cares, even though one may be specified in the file) and don't try to use SVG files as background images. There are ways to do both but chances are you'll suffer unnecessarily.
Do not mess with JavaScript and CSS
Over the past 15 years there have been several techniques to make JavaScript and CSS loading faster. Typically they boil down to the following techniques: combining files, minifying files, GZipping files and moving the JS/CSS loading to the bottom of the HTML document.
Do not do any of that. Do not use any plugin which does nay of that. These are incredibly bad ideas in Joomla 4 — and it doesn't need them!
Combining files causes a lot of chicken and egg situations. You need to know which order files needs to be combined in every single page of your site and to debug the mess when something does not work. It also solves exactly zero problems; we talked about how browsers download stuff to prepare the page for display last month.
Minifying JavaScript and CSS files using PHP code is completely counter-productive. This kinda worked about 12 years ago when these files were dead simple. Modern JavaScript and CSS need more specialised, non-PHP code to minify them e.g. Babel and Closure. Most developers minify their code anyway and Joomla has full support for minified files since the early days of Joomla 3.0.
Using a plugin to GZip your files is incredibly inefficient and will result in longer page load times. Last month we talked about how you can have your web server do that more efficiently and tell the browser to cache the static files.
Moving the JavaScript files from the head to the bottom of the page is asking for trouble. If there is an inline script in the head or document body referencing that code the developer reasonably expected to be already loaded your site will appear broken. Joomla 4 supports deferred and asynchronous script loading. If the developer knows their JavaScript can support that they will use that and it has pretty much the same effect (actually, an even better performance gain!) than moving JavaScript to the bottom of the HTML document.
Finally, moving CSS to the bottom of the HTML document creates a bigger issue than it solves. The browser renders the full page unstyled, then reads the stylesheet and has to start all over again. This causes a lot of extra work and makes your site render slower while, at the same time, the page flashes and moves around as it gets re-rendered. That's horrible user experience.
So, please, don't use any plugins which do these things to supposedly “optimise” your site. These were relevant a decade ago but not anymore.
Using a CDN
The biggest performance bottleneck of your site is the delivery of your static files: images, CSS, JavaScript, videos, audio. This is exacerbated by two factors intrinsic to having a site: available bandwidth and proximity to the user.
The available bandwidth is the “speed limit” at which your site's server can push bytes to a client. Sure, you may have a Gigabit fibre Internet connection or a super fast 5G mobile connection on your end. If the server tops out at 20Mbps this, or rather a fraction of this, is how fast all content from that server will arrive to your device.
The proximity to the user has to do with the universe's ultimate speed limit: the speed of light. Some of you are laughing. Well, it's true! All data from your site's servers goes through fibre optic connections, i.e. laser light guided through glass conduits. That's 99.9% of its travel. The other 0.1% may be copper cables (ADSL/VDSL), microwaves (satellite Internet, 5G, WiFi) or electrical pulses (Ethernet). The laser light cannot travel faster than the speed of light — in fact, it travels at about 0.9c, 90% the speed of light or just shy of 270,000 Kilometers per second / 168,000 miles per second. If your server is halfway across the world it needs to traverse about 20,000 Kilometers which gives us about 75 milliseconds. Transferring data takes a roundtrip (send the request, get back the result) so just like that we have an extra 150msec of waiting before anything comes from that server to the user's device. The closer the server is to the user the faster data transfer begins.
Buying more bandwidth from your host may be possible but expensive. Changing the server's location may be impractical, especially if you are serving a geographic location bigger than a single European-sized country or a US state.
The solution to both problems is using a CDN (Content Delivery Network). A CDN has multiple servers called nodes in data centres all over the world. Your static files are cached at those nodes. When a client asks for a page from your site the CDN forwards the request to your server, your server runs Joomla and sends the HTML content back to the user through the CDN node. When the browser, however, asks for the static content of your site — the JavaScript, CSS, images etc necessary to render the page — the CDN node has it cached and delivers it from the node nearest to the user. The CDN also has plenty of bandwidth since they buy it in bulk for much cheaper than your host, meaning that they can saturate a fast Gigabit or 5G connection even though your server can't. The combined effect is a site loading much faster.
There are plenty of CDNs out there. I am using CloudFlare because it's a combined CDN, site optimisation and site security service. The optimisation features it offers can automatically handle compression of your static resources if your server doesn't support that. Depending on your needs, there's a free tier but also paid tiers with many more features.
It's not necessary to use a CDN. If you have a site which will be serving a large geographic area or you expect it to get hammered with requests then, yes, it is something you need to consider. Paying for a CDN is typically much cheaper and much less of a headache than moving to a dedicated server.
