Joomla Cache Explained: Conservative Caching vs Progressive Caching

Joomla cache settings can reduce repeated page-generation work, but choosing between Conservative Caching and Progressive Caching is not simply a matter of selecting the more aggressive option. The main difference concerns modules, not which component views are eligible for caching. Conservative Caching retains individual module controls. Progressive Caching stores the modules displayed on a guest page together and ignores an individual module’s No Caching selection.

That distinction matters on business websites containing changing prices, availability notices, feeds, banners, random content, shopping features, or other guest-facing modules that should not remain unchanged for the full cache lifetime. This tutorial explains the Joomla cache layers, compares the two modes, provides a cautious configuration procedure, and shows how to test and troubleshoot the result. It covers Joomla 6.1.3 and the supported Legacy branch Joomla 5.4.8 as of August 22, 2026. Because release information changes, the versions should be checked again before publication.

How Joomla cache works—and what it does not guarantee

A cache allows previously generated output to be reused instead of performing the same generation work on every applicable request. Joomla includes built-in Conservative and Progressive Caching modes, so no third-party extension is required to enable either one. In Joomla 5.4.x and 6.1.x, the available Global Configuration choices are Off, On – Conservative caching, and On – Progressive caching. The exact wording should be checked on the target installation if screenshots are being prepared. These options are documented in the official Joomla caching documentation, its Joomla 5.4 counterpart, and the administrator-focused Joomla Cache user guide.

Caching may reduce repeated processing, but the reviewed Joomla documentation does not promise a particular speed improvement, search ranking, conversion rate, Core Web Vitals score, or reduction in server load. Results depend on the site’s extensions, template, modules, traffic, storage configuration, and hosting environment. Measure the site before and after each change rather than assuming that a more aggressive mode is automatically better.

This tutorial concerns Joomla’s documented internal cache mechanisms. Browser caches, hosting caches, reverse proxies, and CDNs are separate layers. Clearing Joomla’s internal cache should not be assumed to clear any of those external systems.

The three relevant Joomla cache layers

1. Component-view caching

A component produces the main content area of a Joomla page. The component developer determines whether a view can be cached and which request parameters must make its cached output unique. Importantly, Conservative and Progressive Caching use the same component-view cacheability decisions. Progressive Caching does not, by definition, make more component pages cacheable than Conservative Caching. The distinction between the two modes is primarily module handling, as explained by the Joomla programmers documentation.

2. Module caching

Modules are the smaller blocks displayed around or alongside a component view. Under Conservative Caching, cache-capable modules are handled individually and can use their own Use Global or No Caching setting. A module that does not provide Joomla cache configuration fields is not cached as an individual module under Conservative Caching.

Under Progressive Caching, the modules displayed on a page for a logged-out visitor are cached together. An individual module’s No Caching selection has no effect in this mode. This is the most important operational warning in the comparison, particularly when guest pages contain frequently changing or session-influenced modules. The behavior is confirmed in the official Cache user guide.

3. Whole-page caching

The System – Page Cache plugin is separate from Conservative and Progressive Caching. It stores complete page HTML by URL and is therefore a more aggressive layer. Disable Page Cache while comparing Conservative and Progressive behavior; otherwise, a whole-page entry may conceal what the component and module caches are doing. Page Cache needs its own risk assessment, exclusions, and guest testing.

Joomla Conservative Cache vs Progressive Cache

The comparison is based on the documented behavior in the Joomla 6.1 caching manual, 5.4 caching manual, and user guide. It does not establish that Progressive Caching is always faster; the official material provides no universal benchmark supporting that conclusion.

Why testing while logged in gives misleading results

Joomla’s documented core Page, Conservative, and Progressive cache mechanisms do not cache frontend output for logged-in users. This avoids serving output generated under one user’s access permissions to another user. Progressive Caching is therefore not a special mode for authenticated visitors, and the common statement that Conservative is for guests while Progressive is for logged-in users is incorrect. See the official current caching documentation and Joomla 5.4 documentation.

Do not use a browser session authenticated to the frontend or administrator as proof that caching is ineffective. Keep the administrator open in one browser, but test the public website in a different logged-out browser, a private window, or another clean guest session. This statement applies to Joomla’s documented core mechanisms; an independent CDN, proxy, host cache, or third-party cache may have different rules.

Which Joomla cache setting is safest for a business site?

Practical recommendation: Conservative Caching is the safer general starting point for many business sites because it retains module-level control.

This is an evidence-based editorial recommendation derived from Joomla’s documented module behavior, not an official mandate or universal guarantee. Conservative Caching lets an administrator exclude a cache-capable module when freshness or interactivity is more important than reusing its output. Progressive Caching removes that opt-out for guest output because the displayed modules are cached together. The supporting behavior is documented by the Joomla technical manual and Joomla user guide.

Progressive Caching is not universally unsafe. It may be suitable where logged-out testing confirms that every displayed module and critical guest workflow can tolerate remaining unchanged for the configured lifetime. It should not be selected merely because its name sounds faster or more advanced.

Before changing cache settings

1. Confirm administrator permissions. Changing Global Configuration requires the relevant Joomla ACL permission. Super Users have access by default, while a custom administrator role can receive delegated configuration permissions. Module editing may require additional permissions. Review the official Joomla access-control guidance.
2. Use a backup and staging copy. Back up the site and perform the first change on a staging copy when possible. This is an operational recommendation, not an automatic benefit of caching. The Joomla release guidance also recommends testing production updates on a copy of the site.
3. Record the current configuration. Note the current cache mode, Cache Time, displayed handler, Page Cache plugin state, and any module-specific cache settings so that rollback is straightforward.
4. Disable System – Page Cache for the comparison. Whole-page entries can mask the behavior being evaluated.
5. Check cache-folder usability. Refer to Global Configuration → System → Path to Cache Folder and the options displayed by the installation. Do not assume one universal cache directory.
6. Do not solve file-writing errors with 777 permissions. For Linux-hosted installations, Joomla’s official guidance recommends 755 for directories and 644 for files and warns against 777. These mode values alone do not resolve ownership or hosting-configuration problems; consult the host when necessary. See File Permissions: Linux.

back up Joomla before configuration changes or use a staging copy before editing the production design.

Related guidance: create a Joomla staging site.

Safe step-by-step Conservative Caching configuration

1. Open the cache settings. In the administrator, go to Global Configuration → System → Cache Settings.
2. Select Conservative Caching. Choose On – Conservative caching. This wording applies to the researched Joomla 5.4.x and 6.1.x interfaces but should be checked before publishing version-specific screenshots.
3. Set a cautious global Cache Time. The Global Configuration value is measured in minutes. Begin with a lifetime that the business can tolerate if guest content remains unchanged until expiry. There is no universal best value.
4. Use the handler available on the installation. Do not copy a historical handler list from an old tutorial. Review the options actually displayed on the target Joomla site and follow hosting-specific requirements.
5. Save the configuration. If saving fails, check ACL permissions and filesystem or hosting configuration rather than weakening permissions indiscriminately.
6. Review important modules individually. Open each critical guest-facing module. If it provides a caching control, select Use Global only when caching is acceptable. Select No Caching where freshness or correct interactive behavior requires dynamic output.
7. Check module Cache Time carefully. An individual module’s Cache Time is measured in seconds, unlike the global value in minutes. The unit distinction is documented in the current manual, 5.4 manual, and user guide.
8. Clear old test entries. Clear the relevant Joomla cache groups so that the next guest request reflects the new configuration.
9. Test while logged out. Use a private window and complete the guest test plan below before considering the setting ready for production.

How to evaluate Progressive Caching safely

Evaluate Progressive Caching only after Conservative Caching works correctly and a baseline has been recorded. On staging, switch the global setting to On – Progressive caching, clear relevant Joomla cache entries, and repeat the same logged-out tests. Do not rely on module-level No Caching selections: they have no effect for guest output under Progressive Caching.

Review every critical module shown during public workflows. Risk-based examples include price or stock displays, availability notices, externally refreshed feeds, rotating banners, random content, session-influenced information, and transaction-related modules. Joomla does not define this as an exhaustive list, and a module cannot be declared safe or unsafe based solely on its label. Its extension documentation, cache keys, invalidation behavior, output, and complete guest workflow must be tested.

If any critical module remains stale too long, displays incorrect guest information, or causes a workflow problem, return to Conservative Caching and clear the relevant cache. Progressive Caching should be retained only when every affected module can safely share the selected lifetime.

A practical logged-out test plan

1. Open a clean private window and confirm that no frontend user is authenticated.
2. Visit representative public pages containing different component views and module combinations.
3. Check menus, forms, search, contact routes, calls to action, and any guest transaction or enquiry journey used by the business.
4. Observe modules whose output changes frequently. Confirm that their freshness matches the documented cache policy.
5. Make a controlled content change in the administrator, then revisit all places where that content appears as a guest.
6. Repeat requests before and after the configured cache lifetime. Remember that the global time is in minutes and a module’s individual time is in seconds.
7. Test with Conservative Caching and Progressive Caching separately, clearing relevant entries between runs.
8. Keep Page Cache disabled until the comparison is complete.
9. Record functional results and site-specific performance measurements. Do not infer guaranteed SEO, accessibility, or conversion benefits from enabling a cache mode.

Applicable Joomla core content operations clear relevant component and related module caches after article changes. This documented behavior should not be generalized to every third-party extension: external components and modules may construct cache keys or perform invalidation differently. Review extension-specific documentation and test updates directly. Whole-page cache entries also require separate attention.

Related guidance: check Joomla extension compatibility.

Clearing and maintaining Joomla cache entries

Use Administrator → System → Clear Cache to select and remove relevant cache groups. Clearing entries is useful after configuration changes, extension updates, controlled tests, or when stale Joomla-generated output needs to be regenerated. It does not necessarily clear a browser, CDN, reverse proxy, hosting control-panel cache, or another external layer.

Expired entries also require periodic maintenance because unpurged files can consume disk space. Joomla provides an administrator purge workflow and the following CLI command:

php joomla.php cache:clean

The command requires suitable command-line access and a CLI PHP executable compatible with the Joomla installation. If the host provides cron, cleanup can be scheduled when the site’s needs justify it. Follow the official Purge Expired Cache guide, and confirm the command and workflow against the installed release before relying on automation.

Troubleshooting Joomla cache problems

“Caching does not appear to work”

• Confirm that testing is being performed as a logged-out frontend visitor.
• Verify that caching is not set to Off.
• Remember that a component developer decides whether a particular view is cacheable.
• Under Conservative Caching, verify that the module supports Joomla cache fields and is not set to No Caching.
• Check whether a separate host, proxy, CDN, or browser layer is affecting observations.

“A module is stale under Progressive Caching”

This may be the expected result of Progressive Caching. Guest-page modules are cached together, and the module’s own No Caching setting cannot override the mode. Clear the cache, verify the global lifetime in minutes, and decide whether the page can tolerate that lifetime. If not, return to Conservative Caching.

“The cache expires too quickly—or content stays stale too long”

Check the units. Global Cache Time is in minutes; individual module Cache Time is in seconds. A value interpreted in the wrong unit can cause unexpectedly frequent regeneration or prolonged staleness.

“An article changed, but an old page is still visible”

Joomla core content code clears relevant component and related module caches after applicable article changes, but third-party behavior varies. If System – Page Cache is enabled, editing an article does not automatically invalidate every complete-page entry on which that article appears. Clear the appropriate Joomla cache, investigate Page Cache separately, and then check external cache layers under their own documentation.

“Joomla cannot write cache files”

Check the configured cache-folder setting, ownership, hosting restrictions, and filesystem permissions. On Linux, the official general recommendations are 755 for directories and 644 for files, with a warning not to use 777. Do not assume that changing mode values will repair an ownership or server-configuration problem.

Page Cache is separate—and riskier for interactive pages

The System – Page Cache plugin stores complete page HTML by URL. It is not another name for Progressive Caching. Because an entire response can be reused, it requires more caution on interactive or transactional pages. Joomla’s Cache user guide specifically warns that whole-page caching can cause incorrect shopping-basket behavior when a shared cached page does not reflect the current visitor’s selections.

This does not mean Page Cache always breaks every ecommerce site. It means affected menu items, URLs, or URL ranges must be excluded as appropriate, and the full purchase or enquiry journey must be tested while logged out. Keep Page Cache disabled while comparing Conservative and Progressive modes. If it is later enabled, treat that as a separate change with a separate rollback plan.

Performance, SEO, accessibility, security, and maintenance

• Performance: Caching can reduce repeated generation work, but no universal speed increase or percentage can be promised. Measure the actual site.
• SEO: The supplied Joomla sources do not establish automatic ranking gains from enabling caching.
• Accessibility: Test critical guest pages after changes. Do not assume caching automatically improves accessibility.
• Security and correctness: Joomla’s documented core mechanisms avoid caching logged-in frontend output, but separate third-party or infrastructure caches require their own review.
• Maintenance: Conservative Caching is not maintenance-free. Cache lifetimes, module behavior, third-party invalidation, disk usage, extension updates, and business workflows still need periodic review.

Joomla version applicability

As of August 22, 2026, this tutorial targets Joomla 6.1.3 and Joomla 5.4.8, both released on August 18, 2026. Joomla 6.1 is the current stable documentation branch. Joomla 5.4 is labelled Legacy, but that label did not mean end-of-life on the research date: bug-fix support was scheduled through October 13, 2026, and security support through October 12, 2027. Joomla 6.2 was upcoming and should not be treated as the stable production basis as of that date. See the official Joomla 6.1.3 and 5.4.8 release announcement and documentation version status.

Business-site decision checklist and rollback plan

• Start with Conservative Caching when module-level opt-outs are important.
• Set a lifetime the business can tolerate, remembering that the global value is in minutes.
• Review all critical guest-facing modules and third-party invalidation behavior.
• Test in a private or logged-out browser, including complete guest journeys.
• Disable Page Cache during the comparison.
• Measure results rather than assuming Progressive Caching is faster.
• Record the original settings before each change.
• If stale or incorrect output appears, restore Conservative Caching or the previous mode, clear relevant Joomla cache groups, and retest.

Frequently asked questions

Does Progressive Caching cache more component pages?

No—not by definition. Conservative and Progressive Caching apply the same component-view cacheability decisions. Their principal difference is module handling.

Does a module’s No Caching setting work in Progressive mode?

No. For logged-out output, Progressive Caching stores the displayed modules together, so an individual module’s No Caching selection has no effect.

Is Progressive Caching always faster?

No universal benchmark in the reviewed Joomla documentation proves that it is always faster. Results depend on the site and hosting environment and must be measured.

Why do I see no cache effect while signed in?

Joomla’s documented core cache mechanisms do not cache logged-in frontend output. Repeat the test in a private window as a guest.

Will saving an article clear every cached copy?

Applicable Joomla core content operations clear relevant component and related module caches, but third-party behavior varies. Saving an article does not automatically invalidate every whole-page cache entry where it appears.

Is Page Cache the same as Progressive Caching?

No. Page Cache stores complete HTML pages by URL. Progressive Caching uses the component-view decisions shared with Conservative Caching but handles displayed guest modules together.

What is the safest starting point for most business sites?

Conservative Caching is a practical, evidence-based starting recommendation because it preserves module-level control. It is not a universal Joomla rule, and the correct choice still depends on logged-out testing.

Sources

• Caching Components and Modules | Joomla! Programmers Documentation
• Caching Components and Modules | Joomla 5.4 Programmers Documentation
• Cache | Joomla User Guide
• Purge Expired Cache | Joomla User Guide
• Joomla 6.1.3 & 5.4.8 Security & Bugfix Release
• Joomla! Documentation Versions
• Access Control | Joomla User Guide
• File Permissions: Linux | Joomla User Guide