Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Archive /

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, biapar, Willr, Ingo, simon_w

Speed issues


Reply


26 Posts   10064 Views

Avatar
Blackdog

Community Member, 156 Posts

22 September 2008 at 10:50pm

I think the speed issue should get a bit more attention.

Is anyone else experiencing slow load times for the cms?

Avatar
FlorianH

Community Member, 33 Posts

22 September 2008 at 10:57pm

The site itself is actually fast enough, only the admin center is really slow, I expreienced that too.

Avatar
dashiel

Community Member, 13 Posts

23 September 2008 at 4:47am

yes i'm still experiencing the initial page load being very slow 5-10 seconds. i've set up the caching and verified it's working.

i'm really hoping the flat file creation outlined in this post http://www.silverstripe.com/scaling-silverstripe-with-caching/ works, but i have as yet been unable to get it working in my development environment.

Avatar
Blackdog

Community Member, 156 Posts

25 September 2008 at 11:19am

not sure if server-side caching will really have much effect on the admin.

personally I think the load time is slow due to all the http requests for individual files.

Firebug recorded 149 requests coming in at 1003kb and they took 1minute and 15 seconds.
Surely that is a bit extreme.

Avatar
Ingo

Forum Moderator, 801 Posts

25 September 2008 at 11:10pm

we have to distinguish website loading from cms loading here. in the former we made good improvements for really high-traffic sites with "static publishing". but you're right, the cms weighs about 1MB at initial pageload, which is far from ideal. the flexible interface takes its toll.
theres two main areas we're looking into for optimizing load of external assets:
- ondemand-javascript (see http://open.silverstripe.com/wiki/development/ondemand-javascript)
- minification and combination (already in trunk version of Requirements::combine_files())

it basically comes down to where you want to spend your energy, and I feel in times of broadband our effort should tend towards a stable product (=more bugfixing), even if this means less development attention for browser load times.

Avatar
Double-A-Ron

Community Member, 604 Posts

25 September 2008 at 11:31pm

Yes. Load times for one of my SS sites is 10s usually on first load. This has a lot to do with the shared server I use and have no control over.

Using Yslow, I have managed to speed it up a bit. (Yes, it was really bad at first!). This is all general stuff that you can place in the Htaccess file.

# if we have access to mod_expires, use it to set a far-future expiry date for selected file types.
<ifmodule mod_expires.c>
<filesmatch "\.(ico|pdf|flv|jpg|jpeg|JPG|png|gif|js|css|swf)$">
ExpiresActive on
ExpiresDefault "access plus 1 year"
</filesmatch>
</ifmodule>

# if we have access to mod gzip, gzip all necessary files
<IfModule mod_gzip.c>
   mod_gzip_on Yes
   mod_gzip_dechunk Yes
   mod_gzip_item_include file \.(html?|txt|css|js|php|pl|jpg|JPG|png|gif)$
   mod_gzip_item_include handler ^cgi-script$
   mod_gzip_item_include mime ^text/.*
   mod_gzip_item_include mime ^application/x-javascript.*
   mod_gzip_item_exclude mime ^image/.*
   mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</IfModule>

# Unset ETags
<IfModule mod_headers.c>
Header unset ETag
</IfModule>
FileETag None

# Unset Last-Modified header
<IfModule mod_headers.c>
Header unset Last-Modified
</IfModule>

The only thing left on Yslow's checklist is the minimization of js files and performing less http requests. That combine_files() method sounds like that will be addressed.

The Admin on the other hand, is indeed a big issue. First load is VERY slow for all clients. I have been able to explain this to clients by saying that they never have to wait for anything (much) once it is all loaded, and without that long wait time, things simply wouldn't be as cool in there. ;-)

Avatar
Blackdog

Community Member, 156 Posts

26 September 2008 at 12:11am

Ingo, I see your point but personally I think speed of the cms should be a very high on the list of todos.

It is the first thing people will experience. You can fix bugs in the deep dark depth of an application but if it fails to load within an acceptable timeframe people will never care.

At the moment I explain that there is alot to load and most people accept that.

Unfortunately it is benchmarked against things like Wordpress which is quite quick to load.

Avatar
Hamish

Community Member, 712 Posts

26 September 2008 at 9:09am

From what I'm seeing, combining and minifying script files should make a big difference. Plus the next generation of JIT JS compilers should just make everything quicker all round.

That said, I would not like to see the CMS performance increased at the cost of flexibility or front end speed. WordPress might have a speedy back-end, but it's very singular in purpose.

One thought about optimization - the [url=http://www.doctrine-project.org]Doctrine Project[/url] documentation has a few points about [url=http://www.doctrine-project.org/documentation/manual/1_0?one-page#improving-performance]improving performance[/url] which could be relevant to SilverStripe. Maybe one of the devs could create a doku page with similar tips? There is every chance that some of these CMS issues are caused by inefficient code in custom classes.