C5.7.3.1 Super Slow?
Permalink 2 users found helpful
We are working on our first fully deployed C5.7 site. I can't say I'm a big fan so far, but I do tend to be stubborn about change, so I'm willing to work on that :)
The biggest issue we're facing at the moment is that the site is remarkably slow. Granted, there are a couple thousand pages on the site so I don't expect it to be super fast, but 26 seconds to open a newly created (and empty) page is a bit extreme. 35+ second to get the page into edit really hurts the productivity.
I know the C5 team have said that performance improvements will be coming soon, but am I the only one seeing performance issues this extreme? We're running on a dedicated box with good specs and low load. It can't just be a server issue. We had some slower sites that ran older versions of C5 with 4,000+ pages, but not this bad.
I have the C5 caching turned on, and when I'm not editing the site we can use Litespeed caching a bit (plus APC is installed on the server), but I feel like that's a swine cosmetic solution.
Any recommendations for improved speed? Is Autonav still a primary culprit? Or is it just the fact that there are that many pages to deal with that's a fundamental C5 issue?
The biggest issue we're facing at the moment is that the site is remarkably slow. Granted, there are a couple thousand pages on the site so I don't expect it to be super fast, but 26 seconds to open a newly created (and empty) page is a bit extreme. 35+ second to get the page into edit really hurts the productivity.
I know the C5 team have said that performance improvements will be coming soon, but am I the only one seeing performance issues this extreme? We're running on a dedicated box with good specs and low load. It can't just be a server issue. We had some slower sites that ran older versions of C5 with 4,000+ pages, but not this bad.
I have the C5 caching turned on, and when I'm not editing the site we can use Litespeed caching a bit (plus APC is installed on the server), but I feel like that's a swine cosmetic solution.
Any recommendations for improved speed? Is Autonav still a primary culprit? Or is it just the fact that there are that many pages to deal with that's a fundamental C5 issue?
I'd like to think it's something like that, but we're running the site pretty lean as far as add-ons. We're using the Equinox theme, a couple of blocks that haven't even been employed yet, no social feeds (yet), nothing that would suggest rogue behaviour.
It's a long-shot, but have you tried running it under a different PHP version?
Yes, both 5.4.34 and 5.4.38.
We do have mulitple PHP versions installed on the server so we could possible try a more recent version if there was the expectation of tangibly better performance.
We do have mulitple PHP versions installed on the server so we could possible try a more recent version if there was the expectation of tangibly better performance.
I've also just relaunched my site using 5.7 and am having the same problem. It's a very simple site using the Elemental theme and currently don't have any plugins and it's taking 10.5 seconds just to load the first byte. I have checked my host.
If anyone has any suggestions it would really be appreciated.
Thanks
If anyone has any suggestions it would really be appreciated.
Thanks
@StriderSEO, @chawksworth
Can you post the site links.
Have you run the sites through the basic performance testing sites?
https://developers.google.com/speed/pagespeed/insights/...
http://www.pingdom.com/
http://gtmetrix.com
http://www.webpagetest.org/
The Elemental theme, as is, is not highly optimized. It has to serve a multi-purpose role which includes showcasing all the new concrete5 features and blocks (this makes it a bit heavy).
Can you post the site links.
Have you run the sites through the basic performance testing sites?
https://developers.google.com/speed/pagespeed/insights/...
http://www.pingdom.com/
http://gtmetrix.com
http://www.webpagetest.org/
The Elemental theme, as is, is not highly optimized. It has to serve a multi-purpose role which includes showcasing all the new concrete5 features and blocks (this makes it a bit heavy).
www.canadianfloristmag.com (Site content is incomplete as we're battling the performance issues.)
We have a pretty good .htaccess setup that we use on most/all sites, including setting expires and compression.
Here are some steps we've taken so far:
- reduced the depth of the Autonav
- upgraded to Php 5.5.x then 5.6.x
- CDN for a few files
Of note:
- Litespeed cache helps when we're not editing, but it's a crutch
- Noticeable speed difference between IE (better) over Chrome
- Server is not overloaded. Our server admin typically describes it as "bored"
With C5 caching enabled we can get the home page to 4-10 seconds. Without, it's ranging 15-26 seconds.
Test results:
- Pingdom: 24., 17.6, 4.22 (with C5 cache)
- WebPageTest: 14.2, 23.1, 3.5 (with C5 cache)
- GTmetrix: 16.47, 7.92, 5.58 (with C5 cache)
- PageSpeed: Desktop 96/100
With the above tools there aren't many suggestions I can implement, as they typically refer to content on a 3rd party site (ex: Google Tag Manager) not setting a long enough exires date, etc.
We have a pretty good .htaccess setup that we use on most/all sites, including setting expires and compression.
Here are some steps we've taken so far:
- reduced the depth of the Autonav
- upgraded to Php 5.5.x then 5.6.x
- CDN for a few files
Of note:
- Litespeed cache helps when we're not editing, but it's a crutch
- Noticeable speed difference between IE (better) over Chrome
- Server is not overloaded. Our server admin typically describes it as "bored"
With C5 caching enabled we can get the home page to 4-10 seconds. Without, it's ranging 15-26 seconds.
Test results:
- Pingdom: 24., 17.6, 4.22 (with C5 cache)
- WebPageTest: 14.2, 23.1, 3.5 (with C5 cache)
- GTmetrix: 16.47, 7.92, 5.58 (with C5 cache)
- PageSpeed: Desktop 96/100
With the above tools there aren't many suggestions I can implement, as they typically refer to content on a 3rd party site (ex: Google Tag Manager) not setting a long enough exires date, etc.
wow - that should be loading a lot quicker.
It looks to me as though you've done a good job of optimising the content and the entire page size is a good.
But, your time to first byte is where the issue is. Is MySQL running on the same server?
It looks to me as though you've done a good job of optimising the content and the entire page size is a good.
But, your time to first byte is where the issue is. Is MySQL running on the same server?
Yes, MySQL is on the same server.
We had the box built with heavy MySQL usage in mind. The drives are nice and fast, and drive IO usage is low.
We had the box built with heavy MySQL usage in mind. The drives are nice and fast, and drive IO usage is low.
have you looked in the log files? There aren't thousands of warnings etc being logged without you knowing?
Have you tried the 'webpagetest' recommendations?
Keep alive?
Progressive jpgs?
Keep alive?
Progressive jpgs?
Whats causing your front page being called/redirected twice?
See #1 and #18. The second one shouldn't be happening.
http://www.webpagetest.org/result/150318_B1_19E8/1/details/...
See #1 and #18. The second one shouldn't be happening.
http://www.webpagetest.org/result/150318_B1_19E8/1/details/...
Agreed - I have no idea what's causing that.
I thought earlier today it might be the Modernizr script, but was wrong. No luck tracking it down yet.
I thought earlier today it might be the Modernizr script, but was wrong. No luck tracking it down yet.
Here are screenshots of an online performance test using the Elemental theme home page.
There are two added global blocks added to the page (a Twitter feed and social icons). Outside of those two blocks, everything is default.
This is a shared host account that I pay $3 a month for. I intentionally keep the Elemental theme untouched for testing purposes. The only thing I change is the .htaccess - adding GZIP and site caching.
Despite the unoptimized images (700k+ in slider images) and the theme not being built for speed, site performance through the US is quite good. Even load times for Europe are reasonable (although more appropriate for CDN use). These are first load speeds, viewing other pages in the site will run much faster because they will be using locally cached assets.
An optimized site running GZIP and using local cache will run much faster.
If your site performance is drastically different, then it means you might need to double check that you are following basic speed optimization guidelines.
Using a pre-made .htaccess is a quick and easy way to make a very substantial improvement in site speed.
http://html5boilerplate.com/
https://github.com/h5bp/html5-boilerplate/blob/master/dist/.htaccess...
There are two added global blocks added to the page (a Twitter feed and social icons). Outside of those two blocks, everything is default.
This is a shared host account that I pay $3 a month for. I intentionally keep the Elemental theme untouched for testing purposes. The only thing I change is the .htaccess - adding GZIP and site caching.
Despite the unoptimized images (700k+ in slider images) and the theme not being built for speed, site performance through the US is quite good. Even load times for Europe are reasonable (although more appropriate for CDN use). These are first load speeds, viewing other pages in the site will run much faster because they will be using locally cached assets.
An optimized site running GZIP and using local cache will run much faster.
If your site performance is drastically different, then it means you might need to double check that you are following basic speed optimization guidelines.
Using a pre-made .htaccess is a quick and easy way to make a very substantial improvement in site speed.
http://html5boilerplate.com/
https://github.com/h5bp/html5-boilerplate/blob/master/dist/.htaccess...
I added compression code to the .htaccess file then ran performance tests, it was the favicon.ico and image slider causing the issues. So I've added a favicon.ico and deleted the image slider which have helped but not completely.
I've got it down from taking 11 seconds to load the first byte to about 8 seconds but I'm not sure where to go next. Maybe I should just go with a diffferent theme.
The URL is cjhdgital.co.uk.
Thanks
I've got it down from taking 11 seconds to load the first byte to about 8 seconds but I'm not sure where to go next. Maybe I should just go with a diffferent theme.
The URL is cjhdgital.co.uk.
Thanks
Try putting this in your .htaccess, all my sites have it and it works wonders, first bit is C5 pretty urls:
@chawksworth
Take out of your header.php, not needed or good, it is in the .htaccess code above.
<IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME}/index.html !-f RewriteCond %{REQUEST_FILENAME}/index.php !-f RewriteRule . index.php [L] </IfModule> <FilesMatch "\.(htm|html|php)$"> <IfModule mod_headers.c> Header set X-UA-Compatible "IE=Edge, chrome=1" </IfModule> </FilesMatch> <IfModule mod_expires.c> ExpiresActive on
Viewing 15 lines of 36 lines. View entire code block.
@chawksworth
Take out
<meta http-equiv="X-UA-Compatible" content="IE=edge">
Hi Steevb
This .htaccess was very helpful in speeding up our 5.7 install. Thanks!
Marc
This .htaccess was very helpful in speeding up our 5.7 install. Thanks!
Marc
I'll second that adding the .ico trimmed ~1sec off our first byte times at webpagetest.
WhoIsHostingThis.com reports that you're hosted with Cirtex Hosting.
http://www.whoishostingthis.com/?q=canadianfloristmag.com...
In my experience, slow sites are almost always caused by slow servers. Tweaks such as the ones suggested here are good and I'm sure they help a little but none of them can fix a slow host.
Cirtex is not very highly regarded here:
http://www.hostjury.com/reviews/Cirtex+Hosting...
http://www.whoishostingthis.com/?q=canadianfloristmag.com...
In my experience, slow sites are almost always caused by slow servers. Tweaks such as the ones suggested here are good and I'm sure they help a little but none of them can fix a slow host.
Cirtex is not very highly regarded here:
http://www.hostjury.com/reviews/Cirtex+Hosting...
Thanks, but that's incorrect. We aren't hosting through Cirtex.
Our box is a custom job by a boutique hosting firm. The server is bored, and other sites are plenty fast.
Our box is a custom job by a boutique hosting firm. The server is bored, and other sites are plenty fast.
Sorry, my mistake. Normally a long 'Time to First Byte' means the server is having a hard time assembling all the page components to form the page which is primarily a function of database performance. In my experience, I have only been able to solve this by changing hosts so I'm no use to you here.
During last week's spam attack, this thread lost important posts, including the method StriderSEO used to solve his speed issue.
- it appears that theme LESS variable values that use a path are set to url("/") if no value is set
Here is a repost of the lost posts:
weyboat has posted to a discussion you're monitoring:
Message:
The front page being called twice as pointed our by Phallanx is because of this code in your main.css file on line 8424
try commenting out the background-image declaration and see if it helps..
StriderSEO has posted to a discussion you're monitoring:
Message:
Thanks, nice catch. Looks like a hitch in the theme code, I'll notify the author.
I've commented out that line, cleared cache, etc. Seems to have made some improvement, but WPT is still reporting the double load. I'll give that a little more time and see if it changes on their reports.
mhawke has posted to a discussion you're monitoring:
Message:
Search your main.css for
I see lots of then towards the end particularly with the .c5h variants
This problem is not seen on the Equinox demo page.
StriderSEO has posted to a discussion you're monitoring:
Message:
It's definitely improving! Not quite there yet, but it's certainly a lot better than it was.
StriderSEO has posted to a discussion you're monitoring:
Message:
It looks like there are some variables not populating:
Those empty variables are defaulting to "/"
StriderSEO has posted to a discussion you're monitoring:
Message:
No errors in the php logs, nice and clean.
StriderSEO has posted to a discussion you're monitoring:
Message:
Got it - the theme has a lot of customizable options for background images on various sections of the page. Those settings default to url("/") if no image is selected.
I used a 1px transparent PNG in all those locations.
With all of these changes - particularly the Autonav reduction - we have the timing down to something reasonable. With C5 caching about 3.5 - 5 seconds for the home page. With LiteSpeed cache it's around 1 second.
Looking forward to a productive day of editing and content creation - and hoping these gains are sustainable.
Thanks, everyone, for your help and suggestions!
mhawke has posted to a discussion you're monitoring:
Message:
Is this a problem with the way 5.7 handles customization or is it theme-specific?
Why not just fix the theme instead of putting a band-aid on it by serving a filler image?
AndyJ has posted to a discussion you're monitoring:
Message:
I just hit your page using pingdom from Amsterdam and New York. I ran teh test a number of times and for me it's coming up a consistent 1.14 seconds(ish) in Amsterdam and between 5-600 milliseconds in New York. That seems pretty good.
StriderSEO has posted to a discussion you're monitoring:
Message:
The less I have to edit the theme the better. If I update the theme in the future I don't want to have a thousand little changes to recreate.
I don't know LESS well enough to determine if it's a C5 issue or just a fact of working with LESS. My guess right now is that it's a C5 issue, though not a bug. Since there is a variable for that file it has to default to something ... the theme default is url('/'), but if you leave that blank it generates a 404 delaying the page even more. I'll leave it to people smarter than me to figure a better way to handle it. For now a tiny PNG is a good solution.
- it appears that theme LESS variable values that use a path are set to url("/") if no value is set
Here is a repost of the lost posts:
weyboat has posted to a discussion you're monitoring:
Message:
The front page being called twice as pointed our by Phallanx is because of this code in your main.css file on line 8424
body { background-color: #ffffff; background-image: url('/'); background-position: center center; }
try commenting out the background-image declaration and see if it helps..
StriderSEO has posted to a discussion you're monitoring:
Message:
Thanks, nice catch. Looks like a hitch in the theme code, I'll notify the author.
I've commented out that line, cleared cache, etc. Seems to have made some improvement, but WPT is still reporting the double load. I'll give that a little more time and see if it changes on their reports.
mhawke has posted to a discussion you're monitoring:
Message:
Search your main.css for
url('/')
I see lots of then towards the end particularly with the .c5h variants
This problem is not seen on the Equinox demo page.
StriderSEO has posted to a discussion you're monitoring:
Message:
It's definitely improving! Not quite there yet, but it's certainly a lot better than it was.
StriderSEO has posted to a discussion you're monitoring:
Message:
It looks like there are some variables not populating:
/* Header */ header { background-color: @header-background-color; background-image: url(@header-background-image); background-position: center center; color: @header-text-color; padding-top: @header-padding-top-size; padding-bottom: @header-padding-bottom-size; } /* Banner */ .c5h-banner-wrap { background-color: @banner-background-color; background-image: url(@banner-background-image); background-position: center center; color: @banner-text-color;
Viewing 15 lines of 18 lines. View entire code block.
Those empty variables are defaulting to "/"
StriderSEO has posted to a discussion you're monitoring:
Message:
No errors in the php logs, nice and clean.
StriderSEO has posted to a discussion you're monitoring:
Message:
Got it - the theme has a lot of customizable options for background images on various sections of the page. Those settings default to url("/") if no image is selected.
I used a 1px transparent PNG in all those locations.
With all of these changes - particularly the Autonav reduction - we have the timing down to something reasonable. With C5 caching about 3.5 - 5 seconds for the home page. With LiteSpeed cache it's around 1 second.
Looking forward to a productive day of editing and content creation - and hoping these gains are sustainable.
Thanks, everyone, for your help and suggestions!
mhawke has posted to a discussion you're monitoring:
Message:
Is this a problem with the way 5.7 handles customization or is it theme-specific?
Why not just fix the theme instead of putting a band-aid on it by serving a filler image?
AndyJ has posted to a discussion you're monitoring:
Message:
I just hit your page using pingdom from Amsterdam and New York. I ran teh test a number of times and for me it's coming up a consistent 1.14 seconds(ish) in Amsterdam and between 5-600 milliseconds in New York. That seems pretty good.
StriderSEO has posted to a discussion you're monitoring:
Message:
The less I have to edit the theme the better. If I update the theme in the future I don't want to have a thousand little changes to recreate.
I don't know LESS well enough to determine if it's a C5 issue or just a fact of working with LESS. My guess right now is that it's a C5 issue, though not a bug. Since there is a variable for that file it has to default to something ... the theme default is url('/'), but if you leave that blank it generates a 404 delaying the page even more. I'll leave it to people smarter than me to figure a better way to handle it. For now a tiny PNG is a good solution.
Something like a 30 second+ delay sounds like it's blocking issue and not a performance one.
It could be something like an RSS feed, a Twitter feed, etc, that is timing out and preventing the rest of the page from loading. Could it be some rouge add-on that is trying to hit a server or something?