How to Speed Up a Joomla Site : 12 Fixes, 90 Min [2026]

Your Joomla site takes four seconds to show anything, you were told to “enable caching”, you did, and it made almost no difference. That is the usual experience, because Joomla performance work has a clear order of impact and most advice starts three-quarters of the way down it.

This guide is ordered by impact per unit of effort on Joomla 5.x. Work down and stop when the site is fast enough. Ninety minutes covers the first eight fixes, where nearly all the available gain lives.

Before you change anything: measure the right thing

The most common mistake is optimising toward a single Lighthouse number. It is a weighted composite measured once, on a simulated device, with simulated throttling, and it varies by several points between runs on an unchanged site. Chasing it produces work that improves the score without improving the experience. Measure these instead, and record a baseline first:

Start with TTFB, because that is where Joomla itself lives. At 900 ms TTFB, no amount of image work will make the site feel fast. On decent shared hosting a cached Joomla 5 page typically returns in 150–400 ms; a tuned VPS often under 200 ms. Far outside that and the server side is your problem — fixes 1, 5 and 6 matter more than everything else combined.

Fix 1: PHP version and OPcache

Highest impact, lowest effort, and routinely skipped because it happens in the hosting control panel rather than in Joomla.

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

OPcache keeps compiled PHP bytecode in memory instead of recompiling on every request. Joomla touches hundreds of PHP files per page load, so the effect is substantial on any site that lacked it. Note that max_accelerated_files at the default 10000 can be too low for a Joomla site with many extensions, and once exceeded OPcache silently stops caching new files.

Fix 2: Joomla’s page cache, and choosing the right one

Joomla has two caching layers and people routinely enable the wrong one. Global Configuration → System → Cache sets the view cache — output of individual modules and component views, with Off/Conservative/Progressive options. System → Plugins → System – Page Cache is a separate thing: full-page caching, storing complete rendered HTML and serving it without running most of Joomla. That is where the large win is.

Progressive deserves its reputation. It keys the cache by session, so every visitor generates a copy of every cached item; on a real-traffic site you get tens of thousands of files, disk I/O rises, and the cache becomes the bottleneck. It exists for heavily personalised module output, and if you are not certain that describes you, it does not.

Fix 3: Images

On most Joomla sites images are the majority of page weight, and the gap between an unoptimised and an optimised image library is usually larger than every other fix on this list added together.

Joomla 5’s Media Manager does no bulk conversion. Process images before upload, or install an extension that hooks the upload. With shell access, batch conversion is straightforward:

# Resize anything wider than 1600px, in place
find images/ -iname "*.jpg" -exec mogrify -resize '1600>' -quality 80 {} \;

# Produce WebP alongside existing JPEGs
find images/ -iname "*.jpg" -exec cwebp -q 80 {} -o {}.webp \;

Two free wins that are frequently missed: add width and height to every image, since their absence is the commonest cause of a bad CLS; and set loading="lazy" below the fold but not on the LCP image, because lazy-loading the hero delays the exact thing that metric measures.

Fix 4: Unpublish what you are not using

Every published module runs a query and renders; every enabled plugin is loaded and its handlers registered on every request, whether or not it does anything on that page.

The usual haul on an older site: editor plugins for editors nobody uses, a leftover slideshow module in an unassigned position, an analytics plugin duplicating a tag already in the template, a search module on a site with no search traffic. Individually small; collectively often worth 100 ms of TTFB and a dozen requests.

Fix 5: Gzip and Brotli compression

Joomla’s Global Configuration → Server → Gzip Page Compression compresses HTML output, typically to a quarter of its size, at negligible CPU cost. Turn it on. Better still, let the web server compress everything — HTML, CSS, JS, SVG, JSON — rather than Joomla’s HTML alone. The shipped htaccess.txt has a mod_deflate block to uncomment. On nginx:

gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_types text/plain text/css text/javascript application/javascript
           application/json application/xml image/svg+xml;

If your host supports Brotli, prefer it — it typically compresses text 15–20% better than gzip at comparable speed. Do not enable Joomla’s Gzip and server-level compression on the same content simultaneously; double compression wastes CPU and some configurations produce a broken response.

Fix 6: Database maintenance and session bloat

Joomla’s #__session table is the classic silent performance problem. Every visitor, including every search engine crawler, creates a session row. Joomla garbage-collects them, but the collection is probabilistic and on a low-traffic site can effectively never run, while on a high-traffic site rows accumulate faster than they are cleared.

SELECT COUNT(*) FROM `#__session`;

TRUNCATE TABLE `#__session`;

Two more tables to check on an older site. #__action_logs grows without limit unless the User Actions Log plugin’s retention period is set — 30 days is reasonable. And #__ucm_history keeps 10 versions of every article by default, which on a large site becomes one of the biggest tables in the database; reduce it under Content → Articles → Options, on the Editing Layout tab, where Enable Versions and the maximum number of versions per item are set.

-- Find your largest tables
SELECT table_name, ROUND(data_length/1024/1024,1) AS data_mb,
       ROUND(index_length/1024/1024,1) AS index_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY data_length DESC LIMIT 15;

Fix 7: HTTP caching headers

Static assets should be cached by the browser so a second page view does not re-download them. Joomla does not set these headers — the web server does, and many shared hosting defaults do not set them at all.

# .htaccess
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/jpeg               "access plus 1 year"
  ExpiresByType image/webp               "access plus 1 year"
  ExpiresByType text/css                 "access plus 1 month"
  ExpiresByType application/javascript   "access plus 1 month"
  ExpiresByType font/woff2               "access plus 1 year"
  ExpiresDefault                         "access plus 2 days"
</IfModule>

Long lifetimes are safe for Joomla’s own assets, which carry a version query string that changes with the file. They are not safe for files you overwrite in place: an image replaced at the same path shows the old version to returning visitors for as long as the header says. Change the filename instead.

Fix 8: Template asset bloat

Commercial templates are a common performance liability, because they ship a framework designed to support every layout their demo site offers, and load most of it whether or not you use it.

What you can do depends on the template. Well-built ones offer per-feature toggles — turn off what you do not use. Joomla 5’s asset manager also lets a template or plugin deregister an asset another extension requested, which is the clean fix for a duplicated library. Do not hand-edit template files; use a child template. And if a template loads 900 KB of CSS with no way to reduce it, replacing it is a legitimate performance fix and often the only real one — Cassiopeia is lean and a reasonable base.

Fix 9: Reduce HTTP requests sensibly

Joomla and various extensions can combine and minify assets. On HTTP/2 and HTTP/3 — nearly all hosting now — combining is much less valuable than it was, because multiplexing removes the per-request penalty that justified concatenation. Minification still helps, since it reduces bytes; combination now mostly helps when you have dozens of tiny files. Test both ways rather than assuming, and note that aggressive combination is the most common cause of “the site broke after I enabled optimisation” — it changes execution order, and scripts depending on that order stop working.

Fix 10: A CDN, when it is actually the answer

A CDN serves static assets from near the visitor. Worth doing when your audience is geographically distant or image bandwidth is large; near useless when audience and server share a country and TTFB is dominated by slow PHP. Full-site proxy CDNs, where all traffic routes through the CDN, additionally give edge HTML caching, TLS termination and DDoS protection, and are usually the better choice. Free tiers suit most small sites; paid plans typically start around €20/month.

Fix 11: Fonts

Web fonts are a common LCP problem and a common CLS problem simultaneously. Three rules cover most of it.

Self-host rather than using a third-party font service: it removes a DNS lookup and TLS handshake to another origin, and a third party from your privacy posture. Subset to the characters you need — a full family with every weight and language range is often 400 KB where a subset is 30 KB. And set font-display: swap so text renders in a fallback immediately instead of staying invisible.

@font-face {
  font-family: 'Inter';
  src: url('/media/templates/site/mytemplate/fonts/inter-subset.woff2') format('woff2');
  font-weight: 400;
  font-display: swap;
}

Two weights of one family is nearly always enough. Four weights across two families is a design decision with a measurable cost worth knowing before you make it.

Fix 12: Know when the answer is better hosting

There is a floor to what configuration achieves. If TTFB stays near a second after PHP 8.2, OPcache, page caching and a tidy database, the server is the constraint — usually an oversubscribed shared host, a PHP worker limit queueing requests under concurrency, or a contended database server.

A ninety-minute running order

1. 0–10 min: Record baseline TTFB, LCP, CLS and page weight, logged out.
2. 10–20 min: PHP 8.2, verify OPcache, raise max_accelerated_files.
3. 20–30 min: Conservative cache on, Page Cache plugin on, test every form.
4. 30–40 min: Gzip or Brotli at the server, expires headers.
5. 40–55 min: Audit and unpublish unused modules and plugins.
6. 55–65 min: Check and truncate the session table; set the action log retention; reduce version history.
7. 65–85 min: Images — resize the worst offenders, add dimensions, lazy-load below the fold.
8. 85–90 min: Re-measure the same four metrics, logged out, and write both sets down.

Then stop. Fonts, CDN and asset combination are worth doing, but they are refinements on a site that is already fast, and doing them first on a site with a 900 ms TTFB is rearranging furniture in a burning room.

Frequently asked questions

Should I use Conservative or Progressive caching?

Conservative, in essentially all cases. Progressive keys the cache per session, so a busy site generates an enormous number of near-duplicate cache files and often ends up slower than with no caching at all. It exists for heavily personalised module output; if you are not certain that describes your site, it does not.

Why did enabling the Page Cache plugin break my contact form?

Because full-page caching serves identical HTML to every guest, including the CSRF token embedded in the form. Visitors receiving a stale token fail validation. Add form pages to the plugin’s exclusion list and re-test logged out. Always test every form after enabling page caching.

Is a Lighthouse score of 100 worth chasing?

No. It is a weighted composite measured once under simulated conditions, and it varies between runs on an unchanged site. The last fifteen points typically cost more effort than the first eighty and produce changes visitors cannot perceive. Track TTFB, LCP and CLS from real measurements instead, and treat Lighthouse as a hint-generator rather than a target.

Does Joomla need a caching extension, or is core enough?

Core caching plus a sensible server configuration is enough for most content sites. Extensions add value where they do things the core does not — asset optimisation, critical CSS extraction, image conversion on upload. They do not make Joomla’s own cache faster. Get the core settings right before buying anything.

How often should I clear the cache?

Only when content has changed and you need it visible immediately. Routinely clearing the cache defeats it — every clear forces every subsequent visitor to trigger a full uncached render. If you find yourself clearing constantly, your cache lifetime is too long for your publishing rhythm; shorten it rather than clearing by hand.

Will a CDN fix a slow Joomla site?

Only if the slowness is distance or bandwidth. A CDN cannot make PHP execute faster, so a site with a 900 ms TTFB serving a local audience will see almost no improvement. Fix PHP, caching and the database first; then a CDN meaningfully helps a geographically spread audience.

Is it safe to truncate the session table on a live site?

Yes. It logs out everyone currently signed in, including you, and nothing else. Sessions are transient by definition. If the table is large enough that this is a recurring question, move session storage to Redis or Memcached so it stops being a database problem at all.