Turning on gzip compression should be transparent - it shouldn't affect any of the scripts. Unless you're using something unusual to gzip things as opposed to turning it on in Apache.

I had a look at moving scripts to the bottom as well the other day. It's only the javascript that you would want to do this with, not the CSS. (I went through this:http://developer.yahoo.com/performance/rules.html/)...

But you can really only do this with your own scripts that you add to a theme, not the ones for packages, as I think it all comes down to the way concrete5 handles the header_required output. Perhaps it's something that will be done in the core in the future.

Something to check out though is where any slowness is actually coming from. Moving scripts to the bottom is going to speed up your site if the problem is how quickly it is able to send data, but often it's more to do with how long it takes for your site to actually process a request and start sending data. This is called the Time To First Byte (http://en.wikipedia.org/wiki/Time_To_First_Byte). The TTFB is not going to be affected by re-arranging scripts, so if this is long, it's more to do with the server speed.

I'm not expert on this, but the main tool I use is Chrome's Developer Tools, and the Network tab to show what is actually slowing things down.

I had a quick look at your site:
- The TTFB is pretty high, 2-3 seconds. My point is that without fiddling around with caching or (changing to a better host), this value isn't going to be reduced by re-arranging scripts
- Your page is looking for at least two view.css files that don't exist. When that happens, the server generates a full 'not found' page, and that's a whole complete concrete5 page render, taking another few seconds. So for every page load it's effectively doing three.
It's looking for the page_list and search view.css file, but can't find them. You've obviously overridden them, so even if you chuck in empty view.css files in those top level directories, that's going to be much better than a not-found.

I've attached a screenshot showing the longer TTFB as well as highlighting the two missing view.css files. You can spot that they are missing as they take a long time to process.

Hope that helps!

Thanks so much for your detailed response!
I've copied over the two missing css files and see the improvement there, albeit a small one, but you know what they say - every little helps...
As to the rest - these are things that came up in my GTmetrix report.
Not being able to control where scripts for add-ons are placed (footer is preferred to header) is a problem, but hopefully this will be changed in the core or some wiz will create a script to correct that.

Thanks again, much appreciated :)

You can also try to stop the statistics generation to make your site's performance more faster.

Citytech

If you mean google analytics - the client wants this, so I can't remove it.
If you are referring to something else - could you please provide more details?

Thanks!

There is a statistics option in dashboard. Its not Google analytics, its the sites performance showing graph of visits, no of pages in edit mode, no of current users logged in etc.
You should stop this performance generation to make the site faster. There is a option to do this in dashboard.

Citytech

Ohh that... I never have it on any of my sites...
It's not turned on for this site, either.. meh.

Thanks, will look into it, though I recall reading those threads and getting very confused...

Wowzers! Miser did it for me.
Thanks so much, and a huge thank you @Phallanx for this!

new tool in your toolbox ;)

I would also experiment using full page caching with some of the pages in your site (or with the entire site, if you're not using anything really interactive). It can reduce the amount of queries, which can add up when using a lot of add-ons.

The Concrete5 full page cache introduced in 5.6 was truly a godsend for performance.