How to speed up your Joomla 3, 4, 5, and 6 website

Joomla has a reputation for being heavy. That reputation is half deserved and half outdated. A properly tuned Joomla site running on modern PHP, with a clean template and the right caching layers, will outperform most WordPress installs and hold its own against handcoded sites. This is a version aware performance playbook covering Joomla 3, 4, 5, and 6, the caching strategies that actually move the needle, image and font optimization, template debt, database hygiene, and the server tuning that finally pushes Core Web Vitals into the green.

Know which Joomla you are tuning

Performance work begins with knowing what version you are on, because the bottlenecks and the available tools shift meaningfully between major releases. Joomla 3 is end of life and runs on legacy PHP. Joomla 4 modernized the framework and dropped the MooTools era. Joomla 5 cleaned up the API surface and improved the front end. Joomla 6 continues the modernization with stricter PHP requirements and tighter Bootstrap integration.

• Joomla 3.x. End of life as of August 2023. Tops out at PHP 7.4 for stability and never officially supported PHP 8. If you are still on Joomla 3, the single biggest performance win is to migrate. Until then, focus on caching plugins, image compression, and dropping unused extensions.
• Joomla 4.x. Requires PHP 7.2.5 minimum, but runs cleanly on PHP 8.0 and 8.1. Introduced a modern administrator UI, native Bootstrap 5, and better caching primitives.
• Joomla 5.x. Requires PHP 8.1 minimum. Drops legacy compatibility layers carried over from 4.x, which by itself reduces request overhead. Service Container is now the default and a lot of older overrides will throw deprecation notices that need cleanup.
• Joomla 6.x. Requires PHP 8.2 or higher. Removes the rest of the deprecated 3.x compatibility code, ships with Bootstrap 5.3, and continues tightening the framework. If your extensions are current, Joomla 6 is the fastest mainstream release to date.

Before you tune anything, run a baseline. Use PageSpeed Insights on three or four representative pages, capture LCP, INP, CLS, and total page weight, and write the numbers down. You cannot improve what you do not measure, and a real before-and-after is the only honest way to evaluate what worked.

Caching is the single biggest lever

Joomla generates every page from PHP and MySQL on demand by default. Without caching, every visit hits the database multiple times and re-renders the template from scratch. Caching is what turns Joomla from a per-request CMS into something that can serve static-feeling pages at speed.

Page Cache plugin

The native System Page Cache plugin is the easiest win. It serves an entire rendered page from disk for guest users, bypassing PHP almost entirely for repeat visits. Enable it in System, Manage, Plugins, search for Page Cache, and turn it on. For service sites with mostly static content this can cut response time by 80 percent on cached pages.

Watch for one gotcha: any module or component that outputs personalized content (cart, login state, dynamic forms with tokens) will get frozen into the cached page unless you tell the cache to skip those URLs. Use the Exclusions field to list URL fragments that must always render fresh.

Conservative vs Progressive cache

Joomla offers two cache handlers under System, Global Configuration, System. Conservative caches view output per module per session. Progressive caches every module separately and globally. Progressive is faster on busy sites but uses significantly more disk space and can cause stale content issues if your modules update frequently. For most service sites, Conservative is the safer default. Start there and only move to Progressive after you have validated module behavior.

JCH Optimize and similar extensions

JCH Optimize is the most mature third party performance plugin in the Joomla ecosystem. It combines and minifies CSS and JavaScript, defers non critical resources, inlines critical CSS, lazy loads images, and integrates with Cloudflare or other CDNs. Its automatic critical CSS generation alone often shaves a full second off LCP.

Configure JCH Optimize in stages. Enable combine and minify first, validate the site still renders correctly, then enable defer JavaScript, then enable critical CSS. After each step, run PageSpeed again. If something breaks, you know exactly which setting caused it.

OPcache at the PHP layer

OPcache stores precompiled PHP bytecode in shared memory so PHP does not have to recompile every script on every request. It is built into PHP 7 and 8 and should always be enabled on production Joomla servers. Reasonable defaults in php.ini look like:

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60
opcache.validate_timestamps=1

On a Joomla site of any meaningful size, OPcache by itself can double request throughput. If your host does not have it enabled, ask for it or move hosts.

Object cache: Redis or Memcached

For high traffic Joomla sites, the next layer is an in memory object cache. Joomla 4 and later support Redis and Memcached out of the box under Global Configuration, System, Cache Handler. The object cache stores database query results, language strings, and rendered component output in RAM, which is dramatically faster than disk based cache. This matters most on shared hosting where disk IO is slow.

Images: the largest single weight on most pages

Images are usually the heaviest thing on a Joomla page. They are also the easiest to fix.

• Convert to WebP. WebP delivers 25 to 35 percent smaller files than JPEG at the same visual quality, and every modern browser supports it. Joomla 5 and 6 ship with native WebP support in the media manager. For older versions, use an image optimization extension or convert in bulk with cwebp from the command line.
• Serve responsive images. A 2400 pixel hero image does not belong on a 375 pixel phone screen. Use the srcset attribute or the <picture> element to deliver appropriately sized images per breakpoint. Many Joomla templates handle this automatically; if yours does not, override the relevant layout in your template's /html folder.
• Lazy load below the fold. Add loading="lazy" to every image that is not in the initial viewport. Native browser lazy loading is reliable, free, and adds zero JavaScript.
• Set explicit width and height. Every image needs width and height attributes so the browser reserves the right amount of space before the file finishes downloading. This eliminates cumulative layout shift, which is a Core Web Vitals metric and a ranking factor.
• Strip metadata. A camera JPEG carries kilobytes of EXIF data that no visitor needs. Bulk strip metadata with ImageMagick: mogrify -strip *.jpg.

Fonts and CSS: hidden render blockers

Web fonts are silent killers of LCP. The browser cannot paint final text until the font file arrives, and by default it blocks rendering while it waits. Two changes fix this almost entirely.

First, add font-display: swap to every @font-face declaration. This tells the browser to render fallback text immediately and swap in the web font when ready, instead of blocking on the font request. Second, preload the one or two font files actually used in the above the fold content with <link rel="preload" as="font">. Self host fonts whenever possible rather than loading from Google Fonts, because the extra DNS lookup and TLS handshake to fonts.googleapis.com costs 200 to 400 ms on a cold visit.

For CSS, the goal is to inline the critical CSS needed to render the initial viewport directly into <head>, and defer the rest. JCH Optimize handles this. If you are doing it by hand, run the page through a critical CSS extractor, paste the result into the template index.php inside a <style> tag, and load the full stylesheet asynchronously with the media="print" onload="this.media='all'" pattern.

Template debt: the slow leak no one talks about

A surprising number of slow Joomla sites are slow because of template bloat that has accumulated over years of edits. Old templates inherited from a 2017 commercial framework can ship 600 KB of CSS and 400 KB of JavaScript that the site does not actually use. Every byte costs LCP.

If your template is more than three years old, audit what it loads. Open DevTools, look at the network tab, and identify every CSS and JavaScript file in the head. For each one, ask: is this used on this page? If not, can it be removed or conditionally loaded? Modern Joomla supports unsetting head assets in template overrides, and most performance work on legacy sites ends up being template surgery rather than caching configuration.

For a clean break, consider migrating to a lean modern template like Cassiopeia (the default in Joomla 4 and later) or one of the lighter commercial offerings. A fresh template often delivers a 40 to 60 percent reduction in page weight on its own.

Database hygiene

Joomla databases accumulate cruft. Old session rows, expired cache tables, deleted articles still in the bin, plugin tables from extensions you uninstalled three years ago. None of this is fatal individually, but it slows every query.

• Empty the trash. In Articles, Categories, Menus, and Modules, switch the filter to Trashed and permanently delete what you do not need.
• Clear old sessions. The #__session table can grow large on busy sites. Truncate it during a maintenance window; users will be logged out but no data is lost.
• Run OPTIMIZE TABLE. In phpMyAdmin, select all Joomla tables and run OPTIMIZE TABLE. This defragments tables and rebuilds indexes, often cutting query time noticeably on large tables.
• Use a cleanup extension. Tools like Admin Tools Professional or JFix can identify and remove orphaned rows from uninstalled extensions in one pass.

Server tuning

The fastest application code in the world is still bottlenecked by a slow server. Joomla performance on cheap shared hosting will always be limited.

• PHP 8.x is non negotiable. PHP 8 is materially faster than PHP 7, often 20 to 30 percent on real Joomla workloads. If your host still defaults to 7.x, switch in cPanel or move hosts.
• LiteSpeed or Nginx beats Apache. LiteSpeed in particular has native page caching that runs at the server level, before PHP even loads. On compatible hosts, LSCache for Joomla is the single fastest caching option available.
• HTTP/2 or HTTP/3. Confirm your host serves over HTTP/2 at minimum. Multiplexed connections eliminate the head of line blocking that throttles HTTP/1.1.
• Cloudflare in front. A free Cloudflare account gives you a global CDN, automatic Brotli compression, image optimization options, and DDoS protection. Cache static assets aggressively at the CDN edge.
• Brotli compression. Brotli beats gzip by 15 to 25 percent on HTML, CSS, and JavaScript. Enable it in cPanel or in your .htaccess with mod_brotli.

The Core Web Vitals scoreboard

All of the above feeds into three numbers that Google actually measures: LCP, INP, and CLS. Tune for the metric, not the gut feeling.

• LCP under 2.5 seconds. Hero image optimization, font preloading, critical CSS, and OPcache do most of the work here.
• INP under 200 milliseconds. JavaScript on the main thread is the enemy. Defer non critical scripts, remove unused libraries, and avoid synchronous third party tags. INP replaced FID as a Core Web Vital in March 2024 and is stricter.
• CLS under 0.1. Explicit dimensions on images, embeds, and ad slots eliminate the jumping that hurts CLS.

Joomla is fast when it is tuned. The reputation for slowness comes from neglected sites running outdated templates on PHP 7 with no caching. Get caching right, get images right, get the server right, and your Joomla site will outperform a stock WordPress install on the same hardware. If you want help running this playbook on your own site, that is what we do every week.