Joomla Performance Tuning III: Static Media Optimization
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.
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:
If you have enabled Restrict Uploads (you should!) also change the Allowed Extensions to include svg i.e.:
If you have enabled Check MIME Types you will also need to add image/svg+xml to Legal MIME Types, i.e.:
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 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.
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.
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 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.
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.
To be continued
Next month we will be talking about site building callisthenics for those among you who build or customise your site's templates. The final article in this series will be published in two months with tips and tricks about content quality and optimising your content not just for search engines but also your human visitors. Until then, happy site building!
German translation of this article: https://www.jug-zueri.ch/artikel/performance-tuning-in-joomla-teil-3-optimierung-von-statischen-medien
Spanish translation of this article: https://mejorconjoomla.com/noticias/magazine/puesta-a-punto-del-rendimiento-de-joomla-4-parte-iii-optimizacion-de-medios-estaticos
About adaptive images: there's a free plugin that I maintain since 2016 that does all that is mentioned here plus:
- Proper cache invalidation
- WebP format
- Avif format
- Support either GD or Imagick processors
and many more. Available here
So, for Joomla 4, are the likes of JCH Optimize Pro no longer needed?
Correct. In fact, you should not use it to prevent it from breaking more things than it fixes.
Use HTTPS so that HTTP/2 and/or HTTP/3 are supported. This reduces the overhead for multiple requests to the same server. Let Joomla handle async / deferred scripts. All this works towards reducing the page render time which is the metric you site's speed is measured by (technically it's FCP and LCP, I am simplifying this a bit).
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.
webp is a supported image format on safari for ios and macOS 11 Big Sur and later.
Only Safari 15 supports WebP. Safari 15 is an optional update for Big Sur. This leaves us with about 30% of Apple devices unable to use WebP. I forgot to change the “all versions” to ”all versions before Safari 15” when I was adapting this article for JCM.
By accepting you will be accessing a service provided by a third-party external to https://magazine.joomla.org/