Cache in Joomla

1. The Basics

1.1 What is com_cache?

A Joomla component is a small application that runs inside Joomla. Most components are about something: com_content is about articles, com_users is about users. com_cache is about cached data - the temporary copies Joomla keeps so it does not have to rebuild every page from scratch on every visit.

The component itself is tiny. It has one job split in two: it lets you clear the cache (delete the stored copies) and purge expired cache (delete only the copies that are past their use-by time). It does not create the cache - the rest of Joomla does that. com_cache is the housekeeping screen.

1.2 What is a Cache, Really?

A cache is a saved answer. The first time a visitor opens a page, Joomla runs the full work: it queries the database, builds the articles, renders the modules, and assembles the HTML. With caching on, Joomla also saves a copy of the result. The next visitor who asks for the same page gets the saved copy back, skipping most of the work.

Caching trades freshness for speed: you serve a slightly older copy so you can serve it much faster.

That trade-off is the whole story. Everything else in this article is about controlling how old the copy may get and which parts of the site are allowed to be served from a copy.

1.3 Why It Matters

Caching touches the two things every site owner cares about:

• Speed. A cached page skips database queries and rendering. On a busy site this is the difference between a snappy page and a slow one.
• Server load. Fewer queries per visit means the server handles far more visitors before it struggles.

The cost is staleness. If you publish a new article and the home page is cached for 15 minutes, the new article may not appear for up to 15 minutes. Knowing how to clear the cache - and how long it lasts - is part of running a Joomla site well.

1.4 Where to Find It

In the Joomla 6 backend there are two entry points, both under the System menu:

System -> Maintenance -> Clear Cache
System -> Maintenance -> Clear Expired Cache

Both open the same component, com_cache, in two different views. The settings that decide how caching behaves live elsewhere, in Global Configuration (section 6).

3. How Joomla Caching Works

3.1 The Cache Lifecycle

Every cached item follows the same simple cycle:

1. Request comes in.
2. Joomla builds a cache ID for it (a hash of the relevant inputs).
3. Is there a stored item for that ID, and is it still inside its cache time?
     YES -> return the stored copy. Done. (a cache "hit")
     NO  -> do the real work, store the result, return it. (a cache "miss")

The cache ID is the key idea. Joomla builds it from the things that should make the output different - the option, the view, the Item ID, the language, the user's access groups, and so on. Two requests with the same inputs get the same ID and therefore the same copy.

3.2 Cache Groups

Items are organised into groups, almost always named after the component that created them: com_content, com_modules, com_plugins, plus a few internal ones like _system and com_templates. The group is what you see and tick on the Clear Cache screen. Grouping means you can clear one component's cache without touching the rest.

3.3 Where the Cache Lives

With the default File handler, cached items are plain files in two folders:

cache/                 (the site / frontend cache)
administrator/cache/   (the backend cache)

Inside, each group gets its own subfolder, and each item is a .php file whose name is the cache ID. The file starts with a die line so it cannot be read directly through the web. You can safely delete the contents of these folders by hand if the backend is unreachable - it is the same as a full Clear Cache.

3.4 Which Tables Feed the Cache

A point that surprises developers: com_cache has no database table of its own. The cache is files or memory, never rows. What it stores, though, is the rendered result of ordinary queries. When a view or page is cached, it is built from content tables such as:

#__content       Articles
#__categories    Categories
#__modules       Module content and page assignments
#__menu          Menu items (drive the cache ID via Itemid)
#__extensions    Component and plugin settings
#__session       Login state (decides guest vs logged-in caching)

The cache layer sits between these tables and the response: on a hit, Joomla skips the queries against them entirely.

5. Cache Handlers: Where Items Are Stored

The cache handler decides the storage medium. Joomla 6 ships four:

Older Joomla versions also offered XCache, eAccelerator, WinCache, and a plain database handler. These are gone in modern Joomla - do not expect them.

5.1 Choosing a Handler

• File is fine for most small and medium sites. Its only real weakness is many small files on slow disks.
• APCu is the easy win on a single server: it keeps items in memory, so there is no disk I/O. It does not survive a PHP restart and is not shared between servers.
• Memcached or Redis are the right answer for load-balanced clusters, because every web node reads and writes the same shared cache. Redis adds optional persistence and is the common modern choice.

5.2 Platform Specific Caching

The Platform Specific Caching option (the cache_platformprefix setting) adds the browser/device type to the cache ID. Turn it on only if you serve genuinely different HTML to desktop and mobile from the same URL. For a responsive template that sends the same HTML to every device, leave it off - turning it on simply doubles the number of cached copies for no benefit.

7. The Page Cache Plugin

7.1 What It Does

The System - Page Cache plugin (plg_system_cache) caches the entire rendered HTML page. When it scores a hit, Joomla returns the stored page almost before the application fully boots - this is the fastest cache Joomla has.

Enable it at System -> Manage -> Plugins, search for System - Page Cache, and turn it on. It uses the same handler and cache time as the global settings.

7.2 Guests Only

The most important rule: the page cache only serves logged-out (guest) visitors. The moment a user logs in, the plugin steps aside and serves them a freshly built page. This is deliberate - a full-page cache cannot safely share one stored page between a guest and a logged-in user, or between two different logged-in users, because the page contains personal details such as their name or cart.

7.3 The Plugin Options

Use Browser Caching deserves a warning: once a visitor's browser holds the page, your server cannot tell it to refresh until the time runs out. Leave it off unless you understand the consequence.

7.4 What to Exclude

Always exclude pages that must be live or personal: contact forms, search results, login and registration, carts and checkouts, and any page with a per-visitor token. Page-caching those leads to submitted forms that "do nothing" or stale tokens that fail security checks.

9. Under the Hood: The Caching API

Caching is available to any extension through a small, consistent API. There are four cache controllers, each suited to a different kind of data.

9.1 The Callback Cache (Most Useful)

The callback controller is the everyday tool. You hand it a function and its arguments; it runs the function on a miss, stores the result, and returns the stored value on a hit. The modern way to get a controller is through the cache controller factory:

use Joomla\CMS\Cache\CacheControllerFactoryInterface;
use Joomla\CMS\Factory;

$cache = Factory::getContainer()
    ->get(CacheControllerFactoryInterface::class)
    ->createCacheController('callback', ['defaultgroup' => 'com_myext']);

$data = $cache->get(
    function ($id) {
        // Expensive work runs only on a cache miss.
        return MyHelper::loadExpensiveData($id);
    },
    [42],          // arguments passed to the callback
    'item-42'      // an optional cache ID
);

The older shortcut still works and is common in existing code:

use Joomla\CMS\Factory;

$cache = Factory::getCache('com_myext', 'callback');
$data  = $cache->get([MyHelper::class, 'loadExpensiveData'], [42]);

9.2 The Output Cache

When you have already built a string of HTML and just want to store it:

$cache = Factory::getCache('com_myext', 'output');
$id    = 'sidebar-' . $itemId;

if ($html = $cache->get($id)) {
    echo $html;            // cache hit
} else {
    $html = buildSidebar($itemId);
    $cache->store($html, $id);
    echo $html;            // cache miss, now stored
}

9.3 Pick a Good Cache ID and Group

Two rules keep cached data correct:

• Put everything that changes the result into the cache ID (the item id, the language, the user's access level if relevant). Forget one, and you serve the wrong copy.
• Use your component name as the group so administrators can clear your cache on its own from the Clear Cache screen.

11. Caching, Logged-in Users, and Personalisation

The hardest part of caching is keeping personal content private. Joomla handles this in two layers.

11.1 The Access Level Is in the Cache ID

Conservative caching includes the user's view access levels in the cache ID. A guest and a registered user therefore get different cached copies of a view, so a guest never receives content meant only for members. This is automatic and correct as long as your own code follows the same rule when it builds a cache ID.

11.2 The Page Cache Stays Away from Logged-in Users

As section 7 explained, full-page caching only ever serves guests. This is the simplest safe policy: anything personal happens on a freshly built page. The trade-off is that logged-in users get less benefit from caching - which is usually fine, since most traffic on a public site is anonymous.

11.3 The Classic Personalisation Bug

The number-one caching bug is a personal value baked into a shared cache: a "Welcome, Peter" greeting cached and shown to everyone, or a per-user token cached into a form. The fix is always one of three things: set that module to No Caching, exclude that page from the page cache, or add the user id to the cache ID so each user gets their own copy.

13. SEO and Performance

Caching is one of the most direct SEO levers you have, because page speed is a ranking and user-experience factor.

13.1 Speed and Core Web Vitals

A cached page reaches the visitor faster, which improves Time To First Byte and helps the Core Web Vitals that search engines watch. For a content site with many guests, the page cache plugin plus Conservative caching is the cheapest meaningful speed gain available.

13.2 Do Not Cache Yourself Out of Fresh Content

Long cache times help speed but hurt freshness. A news site that caches for 60 minutes may show old headlines to search-engine crawlers and visitors alike. Match the cache time to how often your content really changes, and clear the cache after publishing something time-sensitive.

13.3 Caching Does Not Replace the Basics

Caching makes Joomla return the page faster, but it does not shrink oversized images, remove render-blocking scripts, or fix a slow template. Treat caching as one part of a performance plan, not the whole of it.

13.4 Cache Warming

The first visitor after a cache clear pays the full cost of rebuilding every page - a cold cache means a slow first hit and, on a busy site, a spike in server load. Large sites avoid this with cache warming: pre-generating the cache before real visitors arrive, usually as the last step of a deployment.

Deploy finishes
   |
Warm-up script requests the key pages
   |
Joomla renders each page and stores it
   |
First real visitor gets a cache hit

A simple warm-up is a script that requests your most important URLs - the home page, the top categories, the busiest articles - so each one is cached before traffic arrives. Pair it with the deploy-time cache:clean from section 10.3: clear first, then warm, so visitors never meet a half-old site or a cold cache.

15. Best Practices

If you remember only a few things from this article, remember these:

• Use Conservative caching on production; avoid Progressive unless you have tested it.
• Add the System - Page Cache plugin for a real speed gain - it only ever serves guests, which keeps it safe.
• Set personalised modules to No Caching, and exclude forms, logins, and carts from the page cache.
• Match Cache Time to how often your content changes; lower it for news, raise it for brochure sites.
• Clear the whole cache as the last step of every update or deployment, with the button or cache:clean.
• On a cluster, use Redis or Memcached so all nodes share one cache.
• Schedule Clear Expired Cache so the cache folder does not grow without limit.
• When developers cache their own data, put every varying input in the cache ID and use the component name as the group.

17. Summary

Joomla's cache system is the fastest way to make a site feel quick, and com_cache is the small screen that keeps it under control:

• com_cache does two things: Clear Cache (delete stored copies) and Clear Expired Cache (delete only stale ones).
• The behaviour is set in Global Configuration: the caching level, the handler, the cache time, and the path.
• Conservative caching is the safe default; Progressive trades safety for speed and often breaks modules.
• The handler chooses the storage: File by default, APCu for one fast server, Redis or Memcached for a cluster.
• The Page Cache plugin caches whole pages for guests only - the biggest single speed win, with exclusions for forms and personal pages.
• Developers cache their own data through the callback and output controllers, and clear it with cleanCache() or the onContentCleanCache event.

Once you see caching as a set of layers - view cache, module cache, page cache, and maybe a CDN on top - the strange "stale content" problems stop being mysterious. Each layer has a copy, and each layer has a way to clear it. If your site is slow, or shows content you know you already changed, the cause is almost always one of these layers, and knowing how Joomla caches is the quickest way to find it and tune it safely.