I've seen concrete5 installs that are slow, but its usually some developer's box that's running dozens of other things and haven't been regen'd for years.

I personally find connections to this site to be annoyingly slow at times, but when I go reset my comcast modem its super fast again. Something about comcast cable and the path to our server is unhappy at times.. weird..

I know running eAccelerator on a machine will speed up everything, but I guess the real question is where is it slow for you??

I have a shared host plan. When I tinker with C5 and put a new complete set, it is slow getting all the things set into cache.

The one thing I have noticed is that if your dbserver is a separate box, the connection slows there at times depending on the load of that server.

Otherwise, I haven't experienced any real bad slow loading at all. The only other thing that may be slow in loading (for me anyway) is if there are a lot of flash components.

-bill

Maybe you switched off your browser's cache. Then all css and javascript files will be loaded again on every page load.

In my experience c5 isn't any slower than other cms's I used.

I have some personal sites I'm in the process of moving off of MediaTemple's grid server. I've noticed that when I disable the cache entirely (which dramatically increases the number of SQL queries - and is only something you can do through the UI in our current beta versions) it actually appears to increase performance on the grid server, because the grid server has such crappy disk IO (and the concrete5 caching does a lot of disk reading and writing.)

I moved a personal site from the grid server to getconcrete5.com and the speedup was dramatic.

I was thinking the same thing. One of my c5 installs has so many cached objects in there. For a simple data object I don't see how scanning thousands of files in a folder can be that much better than an indexed db call. When you've got complex objects that are constructed by a bunch of separate database calls then it may make sense to cache to disk. In regards to the discussion app, having these cached objects have offered a large performance gain though. When I've cached data objects before though, it's always been a run-time, in memory cache, so if that same object is called again during that page load it doesn't have to make another trip to the database. I'm sure there are trade offs with different approaches.

@andrew, so you felt a big shift going from the c5 servers from mediatemple? i've been considering shifting my hosting (right now icdsoft) but debating which system would be best, c5 vs dedicated virtual...

Dedicated Virtual is definitely better than their basic grid, in terms of performance, but unless you need complete access to your server, you'd be better served by getting our $25-dollar/month commercial hosting

http://www.concrete5.org/hosting...

(I do work for concrete5, of course, so I can't totally claim to be non-biased ;-) )

that being said, it's worth differentiating between browser side and server side performance. Most calls to a webpage on a server take a fraction of a second to process on the server. If the server is getting pounded and running into resource limits, then this may get backlogged, and in that case it makes a lot of sense to concentrate of things like object caching and db optimization etc. But the vast majority of page load time tends to be more browser side: in loading page assets, rendering the dom and css, and executing javascript. The yslow guy from yahoo has done a lot of work on this subject:
http://ajaxian.com/archives/ajax-experience-videos-performance-and-...

A lot has already been done with c5 in regards to smart caching of front-end assets. One small optimization that I'd like to see in there though is a php script to join some of the javascript and css into just fewer files. Right now a basic c5 install is included 27 different css and javascript files, so we can definitely cut that down some. It won't make a huge difference, but less trips to the server helps, since most browsers are limited to only retrieving a couple of files at a time. We could group the files into edit-mode javascript, edit-mode css, and then non-edit mode javascript and css. I've attached an example php script I wrote a while back that joins files, caches the result, and kills the cache when a file is updated.

We could probably do a bit too in terms of load time javascript optimization, but that may deserve its own discussion.

The admin side of it definitely references a lot of external files, but there are places where concrete5 could be improved.

I have a header_required file from 5.2 that I used to load jquery min and swfobject from google's repository instead of from the local server, this seems to work pretty well to speed up load times.

Like concrete5 explicitly loads jquery. I know this is legacy from when everything had in-line javascript, but now since we can add anything to the header from a block this shouldn't explicitly be added, but it would break a bunch of legacy blocks that require jquery to just be there.

@tony, do you have any good resources where one could learn about how to cache certain c5 files? i feel like my site gets bogged up sometime with all the different applications on it . . .

As mentioned elsewhere in this post, slowness is sometimes in the browser. I wonder if it would help to have a footer_required.php where JavaScript is loaded that doesn't necessary affect the appearance of the page on load.

I believe that downloading JavaScript halts the browser during that process, whereas pictures and other simple elements can be retrieved in parallel. The pause for JavaScript is required because something in the JavaScript might affect the next elements in the document to be loaded. Thus, you cannot proceed until the JavaScript is all settled in and ready to go. Loading the page first and then the JavaScript would make it appear that the document loads faster.

This can't be done with all JavaScript, of course. If you have something displaying pictures, for example, you might see flashing as the page is loaded and then the JavaScript updates the page with the pictures. However, it is something to consider.

5.4 is much faster in many ways.
it also uses Zend cache, which if you properly set it up is blisteringly fast.

as with many things, its default options seem to be wrong and over greedy on garbage collection..

here's some thoughts if you haven't found them:
http://www.concrete5.org/documentation/developers/system/performanc...

I've recently set up a site with CC5 - first time using it. Fantastic features. Easy to maintain, but like many people have commented; very slow (8-10 seconds to load a fairly simple site if the browser cache was filled or not).

So. I stocked up with caffeine and cooked up some hacksauce and got to work.

I'm not an OOP expert, but I've done my fair share of PHP so know what works and used the "find the crack and stick a crowbar in method" :)

My main focus was the outputHeaderItems (View.php) in the "libraries" directory) for a bit of sorting (after copying to the top directory - of course).

I'm now iterating through the array and picking out script strings, external scripts, inline CSS, icons and rel-stylesheets. All the CSS stuff is placed to the top of the header, followed by icons. Then comes jquery is in the footer) which is now from a the google CDN. All script tags (except jquery) are placed in the footer (including jqueryui).

I've then had to find all the hard-coded "<script" stuff (like the CCM_DISPATCHER_FILENAME and CCM_SECURITY_TOKEN) and make them an addHeadrItems to enable me to move them around.

I've added a css and js minimiier file which, any file that has .css or ,js in the link, gets passed too (so even the cached items get treatment - need to be a bit smarter here).

I've done a few things with mod_rewrite to sort out expiry times to make sure as much is cached in the browser as possible (very little was actually getting cached) and took on-board some of the changes suggested in the previous link like the style sheets (thanks for that Frz)

It 'aint pretty and its definitely not OOP, but now the site loads in about 2-3 seconds and I think if I can find another hook for the CSS and combine/minify them on-the-fly into one, I should be able to get around 1 second. YSlow now reports my site a "B" (instead of "F" as before) but that's mainly due to the advertisement providers not doing their expires and minifying and the number of external js and CSS files.

I have one small problem of not having some functionality when in the dashboard, but it's probably a js file that needs to be at the top or I've commented something out in one of the files somewhere (I'll figure it out).

So well done CC5 team on an excellent product. I'm now a complete fan :)

ooops. Cut and paste error. Jquery isn't in the footer its in the header straight after the icons.

Fixed the issue with the dashboard. Just needed to invoke 'footer_required' at the end of the dashboard .php in the themes/core. So now it works like a charm :)

Just run some page loads tests athttp://www.webpagetest.org (the worst page with adverts and images) And I get AAACDF. Mainly due to all the JS served locally rather than CDN and css not being merged.

With CC5 file caching ON (including full page)
uncached (browser)
first byte: 0.498s Start Render: 1.045s Total 4.022 s

Cached (browser)
first byte: 0.499s Start Render: 0.738s Total 2.053 s

With CC5 file caching OFF and cleared
uncached (browser)
first byte: 0.685s Start Render: 1.242s Total 4.178 s

Cached (browser)
first byte: 0.941s Start Render: 1.039s Total 2.494 s

I think the difference is in the noise margin.

I also have my doubts that turning off CC5 caching does actually turn it off but maybe that's just the way CC5 serves up the CSS url (I haven't really looked)

Excellent work. Can you provide us with some instructions on what and where to edit?

Search concrete on steroids. He posted it there