Jump to content

[Resolved] Page loading speeds


kealan

Recommended Posts

Hello CC Forum,

 

I am having an issue with our sites loading speeds and I am at a loss as to what is causing it. 

The page loading speed for the homepage is in and around the 5-10 second mark which is horrid. There are a few areas regards the content / external calls itself we are working on and we are confident we can get it down to 2-3 seconds, however there is one variable we cannot get around at the moment. The initial first byte time on page load can vary from 1 - 4 seconds, so I suggested to my hosting provider its time to move it over to a vps, interestingly the hosting provider advised that a VPS wont cure the problem I am having with the site that its most likely a problem caused by the .htaccess file /caching/old plugins. After some disagreement we both ran tests and regardless of what is in the .htaccess file the issue persists, in a final test to prove my provider wrong i tested a html site on same server and to my dismay the issue did not occur on the html site the whole thing loaded in under a second. We use memcache and minimal plugins, braintree payments plugin is the only 3rd party. Any thoughts on what might cause this initial delay? is anyone else having this issue with cc6?

site - mcsoutdoorstore.ie

.htaccess file attached + speed test 

Thanks in advance to anyone who read this far

K

 

.htaccess

speed1.png

Link to comment
Share on other sites

There is nothing in the .htaccess file that would or could cause that and it seems a strange statement for your hosting provider to make and you have disproved that anyway.

However trying to compare the load times of a very heavy CMS based homepage with a simple html file isnt comparing like for like - your homepage is pretty big with images that on first visit are not cached - second and subsequent visits are much quicker although still not as quick as they could be.

It will be difficult for anyone to give exact answers without a lot more in depth detail but then I would have thought your hosting company would have been able to analyse that and tell you more.

Ian

Link to comment
Share on other sites

A waterfall from the browser/client's point of view has a lot of merit. But be aware that this environment includes a lot of plumbing outside of your web server's environment - between that datacenter:
* and you
* and the service that you pasted the above screen shot from
* and any other visitor to your site

I will state that what seems to be the biggest time-hog is the Smarty template rendering engine. I can crash PHP just before Smarty is to make the final rendering and the response of the 500 Internal Server Error is near instantaneous. On the other hand, a completed page on my local server as delivered to my browser is still from 1 to 4 seconds. (Disclaimer: I typically do not have caching enabled. So the database accesses are in the hundreds. But the SQL cache gets cleared way too often anyway.)

Please enable CubeCart's debugging (admin, Store Settings, Advanced tab, enable debugging and enter your IP address (www.whatismyip.com) in the adjacent field so that only you see the debug output). At the bottom is the time it took from start to some time just before absolute finish. This includes only the time PHP is running and also includes the time it takes for database communications.

I have XDEBUG installed in my local PHP, which has a Profiler feature called CacheGrind. Triggering a cachegrind burns a lot of time, but the report reflects only the time it takes for each PHP function to execute. I do not yet have the expertise to understand the display that a cachegrind output interpreter shows, but the cachegrind promises to show where the bottlenecks are.

 

Link to comment
Share on other sites

Many thanks for the replies I appreciate my initial question was somewhat vague! 

After enabling the debugging and reviewing the export I definitely seem to be having some unexpected issues, and annoyingly the issue appears to be around caching so my hosting provider was correct. It appears although memcached* is enabled on the server I still seem to be having some problems actually writing some of the cache data back to the host, which appears to be creating a lot of hangups which I can only assume is causing some issues with load times. 

I will raise this back to my provider but I have also included the output below, it appears that mysql data is being cached but nothing utilising memcache. Would appreciate any steer here if there is anything else my side that might be addressable or if I am missing anything else here.  

debuglog.txt

Edited by kealan
*memcached not memcache
Link to comment
Share on other sites

After troubleshooting with my hosting provider for most of the day we managed to resolve some of the 'open_basedir restriction in effect' errors which was server side but could not resolve the bulk of the debug errors.

After doing some research I found that cubecart will be happy running apc, so i disabled memcached and enabled apc at the server level, Cubecart auto-detected the changes which was nice! my page load times are now sub 4 second. I am still not happy with the the fact that the initial call of the homepage is still taking around one full second but as Brian pointed out the smarty system needs a bit of time to come to life. 

Link to comment
Share on other sites

After troubleshooting with my hosting provider for most of the day we managed to resolve some of the 'open_basedir restriction in effect' errors which was server side but could not resolve the bulk of the debug errors.

After doing some research I found that cubecart will be happy running apc, so i disabled memcached and enabled apc at the server level, Cubecart auto-detected the changes which was nice! my page load times are now sub 4 second. I am still not happy with the the fact that the initial call of the homepage is still taking around one full second but as Brian pointed out the smarty system needs a bit of time to come to life. 

Memcached should generally be quicker than APC but if it isnt configured correctly on your hosting server then that isnt much help but to get the best performance out of APC it does need more tuning and configuration.

Time to first byte can be caused by any number of things including poor or slow DNS servers but would need more detailed analysis to determine what the cause is in your case.  A CDN would also help, especially if your customer base is distributed worldwide, as your homepage images are reasonably big.

Brian pointed out that the Smarty debug added a lot of overhead rather than the use of Smarty itself although it does add some

Ian

Link to comment
Share on other sites

Thanks all for your replies. I will try and address all points. 

Resolved?  My load times have stabilised but are still concerns over the first byte time of nearly a second. http://www.webpagetest.org/result/150926_FY_V6J/1/details/

DNS . I considered this but there are a number of other websites with and without a CMS on the same hosting server /dns server that score fine on first byte time, though none on ssl. 

Memcache . I would suspect this is serverside as my hosting provider was able to resolve some but not all of the issues, APC will have to suffice here.   

I have signed up and enabled cloudflare over the last week via the cpanel so I have only made minor adjustments to the caching config on cloudflare itself, only 1 cached item served so far despite having nearly 2000 hits over that same period. Not sure if that's a discussion unto itself.   

Link to comment
Share on other sites

You can make a comparison for your site with and without CubeCart by requesting a PHP file that has nothing but the command to respond with the PHP configuration.

You can find an example of this command in the /setup/info.php file that ships with CubeCart (but after installation, CubeCart will attempt to delete the /setup/ folder).

Comparing the first byte time to get this info page versus the time to get the CubeCart homepage (assuming no external caching) should indicate how much additional time CubeCart is consuming. The common time is how much the server (request and response transit times, web server, PHP startup, et al) is consuming.

Link to comment
Share on other sites

I've looked at the waterfall chart for site - mcsoutdoorstore.ie and the time spent waiting (purple section) which is the period between sending and receiving seems to take a while, much longer then mine when I have compared them. Mine is blocking for longer but have no idea what that is doing or why! Something for me to look into.

Very interesting topic.

 

wf1.jpg

wf2.jpg

Link to comment
Share on other sites

"Blocking", to me, is when the browser has maxed out it's connections to that domain, either from it's own internal limiters ("good browsing" etiquette), or from the operating system's limit on TCP channels. A dozen years ago (several eons in computer-time), one could adjust a setting that allowed each limiter to mave more channels open.

The image above suggests that your browser can open at least 13 channels - that is, make at least 13 simultaneous requests for images or whatever.

Still, they all must flow through the one single internet pipe that represents your home connection to the Internet.

Link to comment
Share on other sites

Hi All,

Here is the results from a simple info.php file on the same server - No issues with First Byte time 

http://tools.pingdom.com/fpt/#!/b4tTpo/https://mcsoutdoorstore.ie/info.php http://www.webpagetest.org/result/150928_W9_K10/1/details/

the info file contained redirects so I have also run the tests on a blank html file on the same server 

http://www.webpagetest.org/result/150928_54_KAR/ http://tools.pingdom.com/fpt/#!/bk5ga/https://mcsoutdoorstore.ie/test.html

All tests are coming back in the sub second region 

My overall homepage loading speed is from 5-7 seconds as per web page test 

http://www.webpagetest.org/result/150928_AB_KTR/1/details/

But is below 2 seconds via pingdom but this seems very unrealistic / gtmetrix is down at the moment 

http://tools.pingdom.com/fpt/#!/bDgPTD/https://mcsoutdoorstore.ie

But a visit to the site will clearly show its not loading anywhere near that, its still 5-7.

With reference to the number of GET requests / Blocking there also may be another factor in play, though this could be waffle as I am on the edge of my experience here! as part of the initial optimisation of the site we deferred the loading of any specific render blocking scripts until after the initial resources are loaded. We are going to try and asynchronously load some of this content and see if we can reduce the overall times, although this will actually usually score us lower on google page speed test. Though this may be pointless if we are maxing out the tcp connections themselves.

 

      

 

Link to comment
Share on other sites

  • 2 weeks later...

Hi all,

 

Just said I would drop a quick update to inform of the progress I have made here with overall site speeds. After much head scratching and testing trying to eliminate the lag with first byte time I just bit the bullet and loaded the site into cloudflare. So far the results have been pretty amazing load times down to 3 second mark which is where I believed it should have been.

https://gtmetrix.com/reports/mcsoutdoorstore.ie/bujB8wkU

The only issues we have encountered so far is that cloudflare is having issues serving content that itself is served via a CDN. So plugins like the facebook like and comment section which is CDN served had to go, they were working but were causing the page to 'melt' for the lack of a better word until 100% loaded. When users scrolled down they areas where this content was due to be loaded the page started scrolling indefinitely leaving streaking white boxes and then snapping back on fully loaded. We also had to set the cloudflare caching to non-aggressive as it was causing the basket and cookie policy reminder to reset when the homepage was called. But overall a huge performance and SEO boost for 0 cost, no need to move to a VPS for the moment, I hope this helps others out there.

 

  

 

speeds.png

Edited by kealan
typo
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...