Measure a representative workload
Choose a public article, a category page, your heaviest extension page and any important logged-in journey. Record the test location, browser conditions, server configuration and whether each request is cold or already cached.
Look at both browser loading and server behaviour. Large images and third-party scripts can slow a page even when the server responds promptly. Busy PHP workers or database queries need different attention. Change one thing at a time so the result is explainable.
Start with the page itself
Resize images for their displayed use, remove unnecessary extensions and assets, and check your template’s output. Keep supported PHP and extension versions. Review logs and resource use before assuming that a larger server or a particular cache product is the answer.
Avoid quoting a universal number of visitors a plan can support. A cached article and a personalised shop page are different workloads.
Choose a Joomla cache deliberately
Joomla distinguishes conservative caching, progressive caching and the System – Page Cache plugin. They operate at different levels; enabling several switches at once makes troubleshooting harder.
Conservative caching allows individual module cache settings to matter. Progressive caching handles modules as a group. Full-page caching can serve previously generated HTML, which makes exclusions and expiry important. Check the current Joomla documentation and the cache guidance for your extensions before changing settings.
On an isolated copy, begin with the least complicated option appropriate to your pages. Note the cache lifetime and storage handler. Test the change, then test again after clearing the cache. A fast repeat visit is not proof that an uncached request is healthy.
Protect dynamic behaviour
Check carts, checkout, forms, login/logout, language changes and access-controlled content. Verify that one visitor cannot receive content intended for another. Core Joomla’s logged-in behaviour does not automatically establish the safety of an extra CDN, reverse proxy or extension cache.
Exclude routes and sessions as required by the application. Do not enable a blanket “cache every page” rule over a shop, administrator or membership area.
Keep freshness visible
After publishing an article or changing a module, confirm when the update appears to an anonymous visitor. Full-page caches may keep serving older content until expiry or explicit clearing. If you have browser, Joomla and CDN caches, record which layer is responsible for what.
Test an ordinary visitor session after each change. Your logged-in administrator session may not follow the same cache path.
Decide whether resources need to change
Compare the same pages, cache conditions and test location after optimisation. Monitor memory, CPU, database activity and errors while using the site. If resource pressure remains, assess a different instance configuration against those observations.
Our Vultr cost guide provides example prices, not measured Joomla throughput. Establish a staging workflow and working backup before a substantial performance change.
Source: Joomla’s explanation of page, progressive and conservative caching. This guide describes a measurement process; it does not report original benchmarks.