While Joomla is one of the most flexible and robust Content Management Systems available, it can suffer in the performance area. There are some common things that can be done to help speed your site up. While the best performance can be seen on a full dedicated server running Lighttpd (It’s MUCH faster than Apache) and a local MySQL database, acceptable performance levels can be achieved with almost any hosting package. For some administrators, upgrading to a dedicated server might not be practical…
We’ll start off this discussion with one of the most common (and most detrimental) problems that I have seen with Joomla (and any other site for that matter). There exist literally thousands of templates made specifically for Joomla, and most of them look quite nice, but most have some severe performance penalties. The problem is that some of the templates out there use upwards of 70 separate images to display the page. Each image generates a new request (which adds the network latency, usually between 0.1 seconds to as much as 1 second) and has to be downloaded. The problem is exacerbated when those images are not as small (in terms of data size) as possible, and when they are not optimized. There exists a GREAT site that will help you determine what template optimizations need to be done, make sure to run your site through it after ever major change (The Website Analyzer).
Encoding your pages with Gzip is an 90% solution… If your server’s processor is faster than your bandwidth (again, 90% of the time), than enabling Gzip compression will actually speed up your site. I say that because gzipping the pages does require some CPU horsepower. Try enabling Gzip and see if your site loads any faster (especially on highly loaded servers). If it doesn’t, or you get CPU warnings from your host, disable Gzip. It can hurt you, but most of the time it does help. The only way to find out is to try it.
All Components are not Good Components
If you look through the Joomla Extension directory, you’ll find a component to do everything you could want (for the most part). The problem is that some of these components are REALLY inefficient and wind up slowing your site down dramatically. If you want an easy way to identify slow components that you may be using, install my page caching component, but don’t enable caching (let it record the page load time for each URL). Then after a week or so, go through the list that was generated, and find the slow URLS. Those components will show you which ones are slower than the rest. If you can, delete the ones that are really slow, and try another product.
Statistics May Seem Nice, but…
They use a ton of SQL queries to get done what they do. They are not worth it at all! If you want nice stats, use Google Analytics to track your users. Stay away from 3pd stats components. They do generate nice stats, but at a huge performance penalty. The only statistic worth keeping is the search queries (from the Joomla config). If you have access to the webserver, you can also disable logging statistics from the server end as well (this process is much more efficient, and only will really help if your server is heavily loaded).
Mambots are Really Powerful, but also Slow…
Take a look at what mambots you are running. If you are not using any of them, then get rid of them (don’t just disable them, uninstall them). Every time you load a page, mambots are called as much as 20 to 30 times. If the code isn’t 100% efficient and needed, it’s a waste of power. This doesn’t mean that if you use the mambot, you should still keep it. There are some mambots that are notorious for slowing a site down. One of these is the AllVideos Plugin. It’s a great solution, but uses a LOT of queries to complete.
SEF is not Server Friendly
One of the best things you can do to a site, is make the URL’s look more better. The Joomla core does an acceptable job, but there are a handful of 3pd components that make really nice URLs. The problem with these components, is that they are not very performance friendly (they use a ton of queries). I prefer OpenSEF to any of the others (But it’s no longer actively developed) as it seems to be a good mix of power, flexibility and performance. Keep in mind, that using SEF URLs is a tradeoff. A good URL will look better to a search engine, and to end users, but it hurts the load time. Think carefully before deciding to enable SEF URLs. One thing you can do, is periodically optimize the database by purging unpublished and invalid URLs from the OpenSEF database (an option in the admin section of OpenSEF).
Enable Caching as Much as Possible
If you can, enable Joomla’s core content cache. It does speed things up when viewing content and modules (mambots don’t need to be processed each time the page is loaded). If you really want to speed things up for unregistered users, take a look at my Page Caching component which caches entire pages. This is probably the best performance gain you can find you unregistered users (the majority of users for 95% of websites). This does not mean that you can forget about the rest of these optimizations, because the registered users will still see the uncached site.
Find the Bad Queries
From the Joomla config, enable debugging. Then view your site, and check out the database queries being executed. You want this number to be as low as possible (under 30 preferably, but under 50 or so should suffice). Start by looking at the recurring queries (ones that are executed over and over). You SHOULD be able to tell what extension is generating the queries by the table they look at (for example, “Select * from jos_opensef_config” is from OpenSEF). There are two ways of dealing with queries that run often. You can either disable that extension, or contact a developer to optimize the extension (either the developer of the extension, or a freelance developer like me).
Stay Away from Bridges
A popular method of incorporating functionality into Joomla is via a bridge. This involves modifying the Joomla core and the core of another program (such as SMF, or Gallery2) to provide the functionality of both. On the surface, this looks great because the other program is often much more refined and has more features than any “true” Joomla extensions available, but underneath is a different story. The problem is that both are independent systems, which means each one needs to load its own “core” (including frameworks, user management, and more). This has a HUGE performance penalty, because you are basically loading two pages for every page loaded. The slight functionality loss of going from SMF to something like Fireboard is well worth the performance gains.
Optimize your Database
The one thing that is put under the most strain in most Joomla installations is the Database server. There are two main ways to optimize the database. Optimize the tables, and optimize the schema. The difference, is that the tables are how the tables actually store the data, and the schema is how they are supposed to store the data. The schema only needs to be optimized once, while the tables need to be optimized regularly (as data is added, edited, and deleted). To optimize the schema, please refer to the article Improving Joomla’s Queries. To optimize the tables go into phpMyAdmin, select all tables, and click “optimize”. To read more about optimizing the database tables, read this section from MySQL.
Finally, Backup and Monitor Your Server
You MUST make regular backups, and move them off your production server. While you may be thinking “What does this have to do with performance?”, it has EVERYTHING to do with performance. Without current backups, how will you be able to restore the site to a known configuration if an install, update or tweak goes bad? A sudden slow down in the site could be from a hack attempt that injected malicious code into your core (unlikely, but possible). What happens if your server decides to bite the bullet? The best way to make the backups is with an automated script (so that you can’t “forget”). There are good ones all over the internet (and one’s probably included in your control panel if you have one), just google it. Remember, before doing anything to a site, BACKUP FIRST!