Ok,

(Mods maybe this topic could be pinned for people to add to)

A few tips to speed up your front end :

- Optimize all your images for the web, most should come in at under 10kb. This will reduce your overall page size and mean that users on a slower connection can visit your site faster.

- Remove "white space" from your template index.php file, all those esxtra white lines are doing nothing other than wasting bandwidth and meaning that Joomla takes longer to display. Remember the longer your site takes to load, the less people that will visit it, and stay reading for a beneficial amount of time.

- Optimize your Css, remove un-needed stuff that does not get used. Then run it through - http://flumpcakes.co.uk/css/optimiser/ . This will have the effect of tidying it all up and making it small, again reducing load times and also your overall bandwidth.

- Sort out your database, go into phpMyAdmin and select all the tables and repair and then optomise them. This will not damage your site and again it will make your pages load in a much quicker fashion.

If people have more tips then please add them below. The ones that I have added are just a sprinkling of things that you can do with Joomla to get it running faster.

Those are all good points 3guk, but they apply to speeding up any website and not necessarily to optimizing Joomla.  To improve the speed of Joomla's delivery is to change the source code itself.

One way to speed up Joomla (or any other CMS with as many options) is just to utilize fewer of the features.  Many people see all the different features that are standard to Joomla and they immediately publish all of them.  My first Joomla based site had the random image module, most popular, polls, and probably a few other features it did not need.  This problem is one of site design and in my case I have been able to calm down over the past couple years and make a slimmer site that still seems to convey more information than the original.  Publishing fewer modules or having fewer features enabled decreases the number of database inquires and reduces the amount of php code that must be processed for any given web page. 

Sometimes, less is more, which is a cliche but still a valid point.

Thats a good point, I disabled loads of extras that I did not need. I will be delving into the code over the next few weeks in order to get joomla running faster and faster.

Thats where I hope this topic is going.

Although these tips are for websites in generel, they also mean A LOT of optimizations for Joomla. Don't underestimate this.

A few tips from me:

General:
Watch out for errors in your template. When you reference a file like arrow.gif and this file is non-existent, the performance of your server will drop immensly.

Take a look here and check for your websites performance:
www.websiteoptimization.com/services/analyze/
This page gives you a summary about your websites objects and has proposals how to improve it.

Joomla specific:
If your server has performance problems, don't enable gzip. This is meant to reduce the usage of bandwith, not the load on your server. The server has to encode all the files in order to send them, which only puts additional load on your page.

If you encounter serious problems and you have SEF enabled, disable it. It's often the source for performance problems

Probably most important of all: Keep your Joomla! version up-to-date! As to this moment, Joomla 1.0.8 is the most recent version and besides the security fixes, there are big performance improvements, that can save up to half of the queries necessary for a page. This has been implemented in 1.0.8!

On the subject of CSS you can force compression and caching by using a bit of code like this at the start of your Stylesheet:

Code: Select all

<?php
ob_start ("ob_gzhandler");
header("Content-type: text/css");
header("Cache-Control: must-revalidate");
$offset = 60 * 60 * 24 * 7 ;
$ExpStr = "Expires: " .
gmdate("D, d M Y H:i:s",
time() + $offset) . " GMT";
header($ExpStr);
?>
... rest of style sheet as normal here ...



Save your template as template_css.php and edit the reference to the template in /templates//index.php to reflect the new name

Code: Select all

<link rel="stylesheet" href="/templates/<name-of-template>/css/template_css.php" />


As Hackwar said above don't force compression if your server is overloaded - but if it is not, go for it.
The normal rule of thumb with a web server is to worry about how long it is stressed, not how stressed it is.
Serving compressed content is often quicker than tying up the server for a longer period serving uncompressed content - but it varies from server to server.


Just to reiterate Hackwars comments about SEF and missing files (especially template images) with older versions of Joomla and $ambo, especially if you are using an older .htaccess file, if you have upgraded Joomla but not the .htaccess file then you should take a look at the newer htaccess files.

Dean

Also, if you have root access, install a PHP accelerator like APC.  This server is running APC and serves up more pages than you want to even think about, but it handles it gracefully thanks to APC.

And remember to save your old css somewhere, because you cannot easily edit the optimized one.

Also enable query caching in your mysql server! Save ALOT! 

Check with debug site if you have any unnessesary queries and also try to reduce the amount of queries! especialy for your frontpage.

Put error reporting to full and check for errors

Install HttpWatch for IE and check if all the images are present and check what takes longer then other stuf.. (you can also compare your preformance with this, for ex. if you optimize your css check if it really loads faster now)

Enable caching in joomla

Compare if your server runs better with gzip enabled of disabled. For a very busy site its sometimes much better to leave it off.

Hackwar wrote:
Take a look here and check for your websites performance:
www.websiteoptimization.com/services/analyze/
This page gives you a summary about your websites objects and has proposals how to improve it.

Thanks. It's a great help for optimizations.

Actually the best way to gzip your css is just to create a file named 'template_css.php' and add the following code into it:

Code: Select all

<?php
ob_start ("ob_gzhandler");
header("Content-type: text/css");
header("Cache-Control: must-revalidate");
$offset = 60 * 60 ;
$ExpStr = "Expires: " .
gmdate("D, d M Y H:i:s",
time() + $offset) . " GMT";
header($ExpStr);
?>
<?php include ('template_css.css'); ?>

Then change your template to reflect the name as stated before:

Code: Select all

<link rel="stylesheet" href="/templates/<name-of-template>/css/template_css.php" />

That way you can still edit your css file through the admin panel.

I have created the file templatecss.php but I didn't understand what to do with the command

Code: Select all

<link rel="stylesheet" href="/templates/<name-of-template>/css/template_css.php" />

Do I have to insert it into the template.css file?

Thanks,
  Luigi

Nope, put it in your index.template.html file, replacing the Link rel that links to the .css version.

Thank you for your reply. Unfortunately, I do not have a index.template.html file. I just have an index.php and the css file.

lboccia wrote:Thank you for your reply. Unfortunately, I do not have a index.template.html file. I just have an index.php and the css file.

Yes this goes in your index.php file in place of the original css link in the head.

For Grafik Optimizing I use:

WebGraphics Optimizer from http://www.webopt.com/ 

I doesn´t know a better software. For a best result you sould read the manual. See the example in this Programm and play a little with it...

Normaly a 500KB File can be "shrinked" to 180-100KB

This was posted on the Rockettheme forum.

Just wanted your opinion:

"FYI, turning the css into a php file probalby will not speed up your site, infact it will probalby slow it down.  All browsers cache css files automatically, so this means they aer only downloaded once.  By converting it into php, even a cached php file, the server has to process it and sends a fresh copy everytime."

Browsers can happily cache gzipped css files, which is what the PHP script outputs, so it doesn't matter whether you compress it or not. The difference is made on the first site load by the browser - if the CSS is gzipped, the initial download is smaller, and hence the page appears faster. Once it has the initial download, it'll be cached, so it won't be downloaded again unless your css changes, exactly as if you'd served an uncompressed css file.

I'd say that gzipping would make little difference for regular visitors, but for first time visitors, a site using css compression is going to appear faster than one without. It all depends on whether you are aiming at repeat visitors or building new traffic.

Compressed CSS is better for server load than uncompressed CSS?

Not really - it uses a bit of CPU load to compress it, but, if you've got caching set up, it can store the compressed version and serve that up if the browser can handle it. What it saves is bandwidth: compressed files don't need to transfer as much data across, so if you're on a very bandwidth limited server, or if your users are impatient, the compressed version will appear faster.

As CPU tends to be "cheaper" than bandwidth, unless you're pushing the CPU usage on your server already, adding CSS compression will add a very small hit to the CPU usage which shouldn't affect your load much, but can save you quite a bit on bandwidth (especially if you have lots of CSS files).

css? common now, everyone is grabbing onto a few 100k of file as a usual suspect beause it is 'easy'.

CSS will not speed up anything in global scale of things...this is for the most part dealt by the clinets/browsers and in 99% of cases it is cached...using server side language to produce css is waste of everything Unless you are using SS to produce dynamic css that are different from page to page...often seen in 'site builders' and even so ones the file is produced it should be 1 time process and result.css saved somewhere on the server...can you say SSI or perhaps Import?Link?...which is what can be found on idex.php

We need to look in direction of the 3-tier ...being that client side is covered...
You can optimise your images and css decorations all you want....(and it helps don't get me wrong) but your bread is made by:
-improved server side code and processes (in this case php or core of Joomla itself..u get what u code yourself or keep the faith in J developers)
-optimised database server (mysql...stored procedures,cached and reused querries,less sessions and dynamic vars...

If any one is running on 'shared' host that provides "unlimited mySQL databses"....ha well guess how many crappy structured DBs can there be on the same server.
You want something faster than the other guy....?
1. dedicated and optimised servers with enough bandwith
2. write your code from scratch...

...and here comes the wrath of Joomla lovers 

css? common now, everyone is grabbing onto a few 100k of file as a usual suspect beause it is 'easy'.

Well yes - partly. And because it works.
Most threads about speeding up a site will concentrate on the INITIAL page load - ie the first page that a new visitor sees (first impressions and all that). Subsequent pages are usually significantly faster due to caching of images, .js files and .css files.

Gzipping of ouptut html as well as other text files can indeed produce very noticeable speed increases - probably far more noticeable to the end user (site visitor) than speeding up the database server from .2 of a second to .1 of a second. For the majority of users the download is the bottleneck - reducing 100KB of css to 5 or 10KB has significant benefits.

If a database server (or the webserver itself) is particularly overloaded and is the bottleneck then forget what I said above - some other course of action such as those you propose will be required.


Dean

Agreed Dean,

.2 of a second to .1 of a second

One experience that I can share that blew me away (as an admin not a dba) was powered by Sybase (belive v 9 at the time).
You are right no website really has that many records to see the difference - talking about 'content' based sites...but on those that are transaction & multimedia heavy  I have seen difference as large as 10 sec. vs. 3 sec. of returned results. Also, have seen the very same databse lock up with alternaitve version of the same querry. "Transaction table" had about 60-70 fields and little over 3 mil. of records. nothing embeded.
Anyhow...ever since I am a beliver of taking extra time to optimise the DB.....now If I had the skills I would be set 
Thanks for letting me rable...dear topic and always fun to bounce of dbas.
All the best!

It's all about initial page load time. Compressing static files for transmission improves it, purely because less data needs to get to the client before it can show the page. Given how complex some CSS files get nowadays, and that the compressed version will probably be cached both on the server (for distribution to subsequent clients) and on the client (for subsequent page loads), you get a small but noticable improvement in initial page load.

Yes, it's not going to be as helpful as optimising other parts of the system, but effort/output wise, it's a couple of seconds work, and gives a noticable improvement. Optimising a poor database structure which isn't used that frequently, however, can take several hours, and give a much smaller improvement - if the queries are being cached, it doesn't matter if the initial query takes longer, since every subsequent one is much quicker.

Also, compressing CSS and HTML is easy to do, even on poor servers. It won't take the site up to dedicated server speeds, but it can make the difference between fairly slow and really slow.

thanks guys this is very helpfull topic

I found this code in order to optimize mysql... what do you guys think?

I dont know any php so can anyone tell if it is up to par...
----------------

# $Id: db_optimizer.php,v 1.2.3 2005/01/05 15:35:20 nualpha Exp $
##############################################################################
##                        ## Database Table Optimizer ##                    ##
##############################################################################
## Optimize all database tables once every 24 hours through a cronjob.      ##
## If a table is damaged, this script will attempt to repair it.            ##
##############################################################################
## Initially Created: 6/8/2004

# Ensure the script execution request is by the server.
if (empty($_SERVER['REMOTE_ADDR']) && empty($_SERVER['SERVER_ADDR'])) {

# Define Constants
define('ERROR_LOG', '/absolute-path-to-your-log-directory/db_optimization_errors.html');
define('DB_LINK', mysql_connect('server_address','sql_login','sql_password'));

# Define databases to be optimized.
$db_name = array('list_of_comma_seperated','databases_here');

foreach ($db_name as $db) {
mysql_select_db($db, DB_LINK);

# Get all tables in the database.
$result = mysql_list_tables($db);

$sim_tab = ''; // Simulate tab with HTML non-breaking spaces.

# Begin table optimizations.
for ($i=0; $i < mysql_num_rows($result); $i++) {
$current_table = mysql_tablename($result, $i);
$opt_table = mysql_query('OPTIMIZE TABLE '.$current_table, DB_LINK)
or error_log("Couldn't optimize the '$current_table' table!
".
  $sim_tab.'MySQL said: '.mysql_error()."
\n",3,ERROR_LOG);

if (!$opt_table && preg_match("/'(\S+)\.(MYI|MYD)/",mysql_error(), $damaged_table)) {
# Repair broken indexes.
mysql_query('REPAIR TABLE '.$damaged_table[1], DB_LINK)
or error_log("Couldn't repair the '$current_table' table!
".
  $sim_tab.'MySQL said: '.mysql_error()."
\n",3,ERROR_LOG);
$opt_table = null;
# Try to optimize the table again.
$opt_table = mysql_query('OPTIMIZE TABLE '.$current_table, DB_LINK)
or error_log("Couldn't optimize the '$current_table' table after trying to repair it!
".
  $sim_tab.'MySQL said: '.mysql_error()."
\n",3,ERROR_LOG);
}
}
}
}
?>

regarding the code above...

It is suggested that you call the code something like db_optimizer.php and put the code outside of your root directory, and run a cron job

It looks ok to me, nothing you can't do with a copy of phpmyadmin. That said I guess if its called with a cron you can do it on a regular basis, hence removing the chances of you forgetting.

supposedly repairing the tables in the database can slow down the site a lot... is there any way around it?  And how do you know if the tables need repairing?

Thanks

casper007

Well to answer your question with another:

If you have the above code set to run, at say 2am, on a Cron job, and it takes less than 10 seconds to optimize/repair everything... how might this slow down your website for Mr. J. Public and his wife, who aren't nocturnal, when they visit your website?

^^

Mr. J. Public and his wife, who aren't nocturnal, when they visit your website?

That was funny.

No, I meant that after your tables are repaired, the site is never the same anymore.  I guess from what I understand it is a bit like your brand new car being in a huge wreck.  Then you got it back from the body shop, it looks fine but doesn't feel like it used to... it lags here and there... alignment is always off... nobody knows why...  etc...

is that true?  If the table is repaired in a database, can it slow the overall performance?  If thats the case, how do you spot if the table is in need of repair?

cheers
casper007