Support

There is no such thing because "used" is a very relative, tenuous, if not outright nebulous term.

Here's a few example off the top of my head.

Let's say you have enabled the System - Backup on Update plugin we ship with Akeeba Backup. Is it used? If you do updates from Joomla's backend it does show you the option to take a backup before update, but if you don't choose to do that, or if you update via another method (third party service, CLI, upload 7 update, manual update, deploying an updated version of the site) are you using it? By one definition you do – it showing a message on the update page if you access it is the plugin being used. By a different definition, since you practically never use it, it's not used.

Is an installed module used? You could have published module instances but they might be published in unused module positions, or restricted to pages which are deleted, unpublished, or nobody visits. By one definition, the module is used – there are published module instances for it. By another definition, these module instances are never shown, so it's not used.

Is a plugin, or module included in a package but not used on your site truly "unused" when uninstalling it will break the package?

All these and many, many more questions cannot be answered with anything other than "it depends" and "you need to ask the site owner". But if that's the case, how can you possibly automate any of that?! You can't. The site owner needs to go through the installed extensions and decide if they have a purpose.

Besides, your problem is neither the page generation time (I am across the world from you, i.e. huge lag due to distance, and I still get the full HTML page downloaded in 0.6 sec), nor the speed of delivering the actual image files (though it can be improved with HTTP/2 preloading).

I strongly recommend reading my Joomla Community Magazine article series from a couple years ago on Joomla performance tuning:

• https://magazine.joomla.org/all-issues/november-2021/joomla-4-performance-tuning-part-i
• https://magazine.joomla.org/all-issues/december-2021/joomla-performance-tuning-ii-basic-settings
• https://magazine.joomla.org/all-issues/january-2022/joomla-performance-tuning-iii-static-media-optimization
• https://magazine.joomla.org/all-issues/march-2022/joomla-performance-tuning-iv-site-building-calisthenics
• https://magazine.joomla.org/all-issues/september-2022/joomla-performance-tuning-v-content-quality 

Your installed extensions may increase the time it takes to generate the HTML page of your site, i.e. increase the response time. That's 0.6 seconds. Culling out the extensions will save you maybe 0.1 to 0.2 seconds at best. However, as you said yourself, this is not where your problem lies. Your problem lies with the client-side rendering. This depends on your HTML structure, your CSS, the number and size of your media files, how you load these etc.

You really need to read the links I sent you. That's what I am talking about in there.

The cookie banner is destroying both your FCP and your LCP. That's true for all floating, Javascript-based cookie banners. Get rid of anything that requires cookies to then get rid of the cookie banner, drastically improving your site's performance. This is where the bulk of improvements lies.

You have a bunch of CSS and JS that's being loaded on every page. Use HTTP/2 preload to hint the server to send them along with the main body response, saving you a whole second to second and a half of round-trip time in requests. I use that extensively on my sites. The downside is that it requires changing the PHP code of the template.

Replace the images in menu items with icons using a custom icon font (which should be preloaded with HTTP/2 preload) to avoid another 8 HTTP requests.

Change your site's header from a huge image to a smaller image and font text effects (or, better yet, switch to a more simplified version rendered with an SVG) to save a lot of loading and rendering time.

The carousel images are too big. You should use a third party extension to serve appropriately sized, auto-scaled WEBP images using a PICTURE element.

Images should be loaded deferred where possible to prevent render blocking in off-screen images. Do note that this will require a bit of testing across screen sizes as it can cause layout shifts on tall displays, like big (24" and higher) desktop screens, and some phones/tablets –especially some Android phones with ridiculously tall 24:10 screens– in portrait orientation.