3

I am trying to get the load times on my website down. It loads really slowly and iv tried a couple of solutions.

  1. Using gmetrix to solve issues such as optimizing images .
  2. Using pingdom to see what the issues are.

As listed in the below link are the pingdom stats. http://tools.pingdom.com/fpt/#!/cKIvOz/http://healthyeatingandliving.ca/

I have no clue what admin-ajax.php is and why the load on that is so high. Also if anyone knows what the first line is in the file/path column .

If there is anything else i can do to make the load times less since right now its a pain trying to edit content. Thank you to everyone who looks at this.

user2189801
  • 83
  • 1
  • 1
  • 11
  • Update : I'v done as suggested by Robert and made it so that woocommerce only loads scripts on the pages it needs. – user2189801 Mar 28 '14 at 15:54
  • Update 2: Did a test with Webpagetest.org and it shows that there is some problem with pie.htc request. Anyone got any clue? [link](http://www.webpagetest.org/result/140328_9K_PS8/1/details/) – user2189801 Mar 28 '14 at 15:54

5 Answers5

3

You should add this code to functions.php inside your theme.

add_action( 'init', 'my_deregister_heartbeat', 1 );
function my_deregister_heartbeat() {
    global $pagenow;

    if ( 'post.php' != $pagenow && 'post-new.php' != $pagenow )
        wp_deregister_script('heartbeat');
}

This code will disable the admin-ajax.php feature and reduce CPU by 75%.

Konstantinos
  • 418
  • 3
  • 10
  • I had the similar issue and tried you solution by adding the code to functions.php of the theme file, but on running a test on tools.pingdom.com it still shows the delay caused by admin-ajax.php. Any suggestion what could be wrong? – user2002522 Jan 07 '16 at 12:03
  • How did you calculate that it reduces CPU load by 75%? – jeteon May 01 '16 at 01:48
2

Screenshot of Network-tab in inspector Use the heartbeat control plugin and disable it. Also, in gtmetrix, click on the waterfall chart and then click on post as indicated in the image to figure out whats wrong.

It's a call to the ajax features from a wp plugin called wptouch.

Sjon
  • 4,989
  • 6
  • 28
  • 46
Sourish
  • 21
  • 2
1

The issue with the ajax load time is with woocommerce scripts running even when you do not have any of the functions needed for your shop on certain pages. I would consider what theses individuals did and have the scripts removed from your regular pages (sorry the website is a little old so you may want to double check and update the enqueue script variables). But to get the gist of it you would basically be removing plugins that are not necessary for the pages that do not require woocommerce functions.

http://wordimpress.com/how-to-load-woocommerce-scripts-and-styles-only-in-shop/

or

http://gregrickaby.com/remove-woocommerce-styles-and-scripts/

You could also add some conditional tags so that it specifically does not load on certain pages.

https://codex.wordpress.org/Conditional_Tags

Robert Lee
  • 1,541
  • 1
  • 10
  • 20
  • Thanks Robert for your reply. So basically i am assuming Woocommerce is a culprit here? I have been doing some research and people say it could be the Heartbeat API in wordpress. I will deactivate woocommerce and see if it makes any difference. I think that should solve some concerns. – user2189801 Mar 28 '14 at 07:01
  • The main problem is that woocommerce loads the scripts regardless of what page you are on since most sites that are designed for woocommerce uses the functions on all pages (where your site does not). if you specify the location that it loads in then you can still utilize woocommerce and only have the specified paths load the necessary information. – Robert Lee Mar 28 '14 at 07:45
  • Did a test with Webpagetest.org and it shows that there is some problem with pie.htc request. any clue why this would be occuring and do you think i can solve it by putting the file in the said location? http://www.webpagetest.org/result/140328_9K_PS8/1/details/ – user2189801 Mar 28 '14 at 16:50
  • Well Pie.htc is a compatibility tool for IE. From your results it looks like HTTP/1.1 404 Not Found. If it cannot find it and you are trying to call for the script then it will hang. I would suggest finding what function/plugin might be calling for this and ensure that the path is correct. – Robert Lee Mar 28 '14 at 17:39
  • Awesome, i turned of all plugins and turned them on 1 by 1. The problem was contact form 7. I was calling a contact form within a plugin shortcode for lightbox. So basically the contact form would show in a lightbox when an image was clicked on. It was causing huge memory hog. – user2189801 Mar 31 '14 at 21:09
1

Another plugin or the theme is using something like a cart widget that refreshes when you add to cart etc, this uses admin-ajax and will load on every page, if you deactivate WooCommerce then the problem goes away but the issue is something that depends on WooCommerce.

Michael
  • 589
  • 2
  • 11
  • 26
1

I've spent a witless few days trying to sort this same issue out, I've even used the deregister_heartbeat code - to no effect. I wanted to share a solution I put in place to keep Apache / MySQL from dying whilst you try to find out what's going on.

In the end after creating a test copy of the site on a different server and swapping to a default theme I was able to work out that an extention engine in a child theme was making Ajax calls that were somehow getting past the deregistered heart beat - we've now ditched the engine and will probably write the child-theme from scratch.

To buy me some time whilst tracking the offending stuff down I needed a way to drop the threads from the webserver before they occupied all available spaces - and we have a big webserver - it was nonetheless causing sites to crash after only an hour since an Apache restart. You can of course employ a hard Apache restart (apachectl restart or service apache restart on a Debian machine) - but this kills all connections - and in a multi-host environment its going to mess someone up. If you are on an *NIX system, you can do the following, it requires w3m (or equivalent braile-mode browser that can run dumps from the CLI like elinks, lynx or links)

#!/bin/bash
kill `w3m -dump http://<server address>/server-status | grep "admin-ajax.php"|awk '{print $2}'`

Make sure you get the backticks right after the kill and at the end of the script. We basically use w3m to hit the server-status page (you need to have this enabled in your Apache config - make it available only from a local IP address, it gives a lot away) - we pipe the results through grep just hone in on processes that deal with admin-ajax.php - and then we feed those lines into awk which basically returns a list of the associated PID numbers to the kill command.

The result is that the process threads in Apache will die - but will appear for a short while in any server-status list as open slot with no current process - subsequent hits to your site will occupy these threads in a normal fashion again

We put the whole thing into a cron task running every 5 minutes or so - effect is we got the threads appearing, but they never stayed around long enough to cause issue.

Steve Nisbet
  • 11
  • 3