It appears that whenever we we get a bad speed score, the Combine CSS/JS is either a D or a C. However, whenever we get a good speed score, we get a B or A in that same category.
We get A’s in all other categories and we DO have a CDN although the speed tests does not recognize it in the score.
Our page speed would be very good but for the CSS/JS compress problems.
We have tried an assortment of compressors/combiners. We have received mixed and inconsistent results and no compressor seems to work.
When we tried finalizer, every time we would do a test and get a C, our speed would be slow and jomcomment error would appear in the CSS/JS results. In fact, we disabled jomcomment and the site went white with no content. WE put jomcomment back on and the site reappeared.
We tried JA Compress since our template is also Joomla Art.
Nope, still high speeds and errors with CSS/JS but great scores for the other categories.
Don’t focus on the front-end right now. You have a serious back-end performance issue that you need to get under control. 11 seconds for the first byte time is crazy - it should be well under 1 second.
Odds are the problem is being caused by a lot of queries to your database and probably poor database performance. You need to turn off any modules that you have installed that you aren’t using and then look into options for query caches or page caches (or both).
The cache we use comes with the template Joomla Arts.
Once we do both, I will report back.
Since we are getting D’s C’s and F’s associated with the Combine CSS/JS, other than the above, I am wondering if you have any specific recommendations for that problem or any specific solutions or fixes for those issues.
Saturday, we tried uninstalling jomcomment since the errors were repeatedly related to that component and in doing so, the screen immediately became white blank. We tried it again yesterday and unfortunately received the same result.
Last, do you think that mod_pagespeed for Apache might help? I have considered this although I understand it is still in beta.
mod_pagespeed would probably help with the combining and other front-end issues. It is still in beta but it is pretty stable, particularly for the basic optimizations. It won’t help with the first byte time though and I recommend not working on anything else until you can get that under control.
As far as caching goes, I would look into the Query Cache module first and then once/if that is working add JotCache on top of it (both should co-exist and cache different aspects of Joomla).
Patrick,
we have followed your suggestions but it appears that our speed has not improved. However, our test scores have changed.
when we last communicated above, one of the tests http://www.webpagetest.org/result/110508_AQ_JJAG/ showed we had F’s in CDN and combine jS/css and the rest were A’s. The speed was 17 secs.
Now, we are getting B’s (sometimes A’s) in CDN and js/css, A’s or B’s in everything else except for combine text which we have an F. We are getting 4’s on the Webpagetests yet when we actually time the opening, we are getting 16 to 20 seconds?
Here is a recent score yet within a minute of the test, we timed the speed of the front page via a time clock and it was about 10 seconds longer than this test. http://www.webpagetest.org/result/110518_K9_MH6R/
Do you have any other suggestions? I suspect it is taking time for the queries to the database but those softwares did not help.
Again, I do thank you for your response and unfortunately this issue is totally consuming my efforts as my online newspaper which is now in the 11th year is way too slow and is turning away readers.
S.
Thank you very much.
I added Blue Hat Network to the list of CDN’s with the most recent release but however you have it implemented is completely wrong. It looks like you are doing redirects from your site to the CDN for static content. That actually DOUBLES the amount of time to load the resources and is way worse than just serving the files from your server directly. That means the actual URLs for the CDN requests need to be changed on the content itself (or with a plugin that does it automatically).
The newer test was also done on IE8 (the default changed yesterday from IE7). When you timed it, was it from a logged-in account? The server-side page caching only works for guest visitors so if you are logged into wordpress you will not be seeing the same experience as your users (and in that case the bulk of the time does come from generating the page).
Something changed to break you text compression (maybe one of the plugins changed the behavior or the .htaccess). That’s actually a prety big deal because the site is delivering quite a bit of javascript (probably worth 1+ second).