Discussions on this article:

Navigation:

Introduced in WordPress 3.6 the WordPress Heartbeat API allows WordPress to communicate between the web-browser and the server. It allows for improved user session management, revision tracking, and auto saving.

The WordPress Heartbeat API uses /wp-admin/admin-ajax.php to run AJAX calls from the web-browser. Which in theory sounds awesome, as WordPress can keep track of what's going on in the dashboard.

However this can also start sending excessive requests to admin-ajax.php which can lead to high CPU usage. Anytime a web-browser is left open on a page using the Heartbeat API, this could potentially be an issue.

WordPress Heartbeat API in action

Something handled by the WordPress Heartbeat API is the main WordPress admin dashboard page itself. If all you did was login to WordPress and then minimized that window and started working on something else, you'd see requests for admin-ajax.php in your site's access logs.

At [00:29:30] I logged into the dashboard, and you can see the initial GET /wp-admin/index.php request.

Then at [00:30:31] the WordPress Heartbeat API sends a POST /wp-admin/admin-ajax.php Heartbeat request.

With the WordPress dashboard in focus, a Heartbeat request should be spaced the max of 60 seconds that the API allows for. If the dashboard is out of focus, the Heartbeat requests space out to 120 seconds between them.

00:29:30 "GET /wp-admin/index.php "http://example.com/wp-admin/index.php"
00:30:31 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:32:03 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:33:03 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:34:03 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:35:04 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:36:04 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:37:04 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:38:04 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:39:04 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:40:04 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:42:04 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:44:04 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:46:04 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:47:04 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:48:04 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:49:04 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:50:04 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:51:04 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:53:04 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:55:08 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:57:04 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
00:59:04 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
01:01:05 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"
01:03:05 "POST /wp-admin/admin-ajax.php "http://example.com/wp-admin/index.php"

Now each of those POST requests had a corresponding PHP script execution on the server using CPU time:

php-cgi 0.26 secs Wed Feb 19 00:29
php-cgi 0.26 secs Wed Feb 19 00:30
php-cgi 0.23 secs Wed Feb 19 00:32
php-cgi 0.20 secs Wed Feb 19 00:33
php-cgi 0.22 secs Wed Feb 19 00:34
php-cgi 0.24 secs Wed Feb 19 00:35
php-cgi 0.20 secs Wed Feb 19 00:36
php-cgi 0.23 secs Wed Feb 19 00:37
php-cgi 0.23 secs Wed Feb 19 00:38
php-cgi 0.26 secs Wed Feb 19 00:39
php-cgi 0.22 secs Wed Feb 19 00:40
php-cgi 0.23 secs Wed Feb 19 00:42
php-cgi 0.22 secs Wed Feb 19 00:44
php-cgi 0.23 secs Wed Feb 19 00:46
php-cgi 0.25 secs Wed Feb 19 00:47
php-cgi 0.27 secs Wed Feb 19 00:48
php-cgi 0.23 secs Wed Feb 19 00:49
php-cgi 0.22 secs Wed Feb 19 00:50
php-cgi 0.21 secs Wed Feb 19 00:51
php-cgi 0.21 secs Wed Feb 19 00:53
php-cgi 0.21 secs Wed Feb 19 00:55
php-cgi 0.24 secs Wed Feb 19 00:57
php-cgi 0.25 secs Wed Feb 19 00:59
php-cgi 0.22 secs Wed Feb 19 01:01
php-cgi 0.23 secs Wed Feb 19 01:03

Having our dashboard open for over a half hour, generated 25 PHP script executions. With a total usage of 5.77 CPU seconds. Not terrible, but not great either, since we used up CPU essentially checking for nothing to happen.

Disable WordPress Heartbeat API

If you notice that you are having an excessive amount of admin-ajax.php requests, the WordPress Heartbeat API can be disabled to prevent this type of activity from happening automatically.

By default WordPress uses the Heartbeat API to manage things such as post locking so only one admin can edit a post at once, it's also used for auto saving. Going forward the API could be used more and more by WordPress developers to handle certain tasks, so keep this in mind if you choose to disable it.

Navigation:


Locate your functions.php script

To modify the behavior of the Heartbeat API, locate your WordPress theme's functions.php script.

I'm using the default twentyfourteen theme, so my path looks like:

/home/userna5/public_html/wp-content/themes/twentyfourteen/functions.php

Make a copy of this file, something like functions.php-BAK for safe keeping.

Disable WordPress Heartbeat everywhere

Towards the top of the functions.php file, add the highlighted code to disable the Heartbeat everywhere:

 * @since Twenty Fourteen 1.0
 */

add_action( 'init', 'stop_heartbeat', 1 );

function stop_heartbeat() {
        wp_deregister_script('heartbeat');
}

/**
 * Set up the content width value based on the theme's design.

Disable WordPress Heartbeat just on Dashboard page

To selectively disable the Heartbeat API on certain pages, you can use the global WordPress $pagenow variable to tell what page a user is on. Along with an if statement to tell WordPress if the Heartbeat API should be used.

You can check if the $pagenow variable is a specific page, and if so turn off the Heartbeat:

add_action( 'init', 'stop_heartbeat', 1 );

function stop_heartbeat() {
        global $pagenow;

        if ( $pagenow == 'index.php'  )
        wp_deregister_script('heartbeat');
}

Disable Heartbeat everywhere except post.php and post-new.php

You can also check if the $pagenow variable is not set to specific pages that you would still like the Heartbeat to happen on, such as post.php or post-new.php, and then turn off the Heartbeat on every page but those.

add_action( 'init', 'stop_heartbeat', 1 );

function stop_heartbeat() {
        global $pagenow;

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

Then just save your functions.php script, after choosing where you'd like the Heartbeat to be disabled.

Delay WordPress Heartbeat requests

You can also leave the WordPress Heartbeat API enabled for all of your pages, and just slow down the rate at which requests happen by modifying the WordPress Heartbeat JavaScript file.

This can be a great method to use if you'd still like to have all the functionality that the Heartbeat API provides by default, but still reduce the overall usage it requires to run.

Change the rate of the default Heartbeat requests

First make a backup copy of this file:

/home/userna5/public_html/wp-includes/js/heartbeat.min.js

Now it can get a bit tricky due to this JavaScript file being minimized, but essentially you want to find the 3 separate cases for request activity, 15 seconds, 30 seconds, and 60 seconds and increase the time of all of these.

In all the examples below, the ...'s indicate that there is other code you don't need to edit in-between the parts you do need to edit.

15 Second requests

To extend the default behavior of having a Heartbeat request every 15 seconds, you would look for this code:

B.mainInterval<15?B.mainInterval=15:...case 15:

Change it to something like 120 to extend Hearbeat requests out to 2 minutes by default:

B.mainInterval<120?B.mainInterval=120:...case 120:

30 Second requests

To extend the behavior of having a Heartbeat request every 30 seconds, you would look for this code:

case 30:...30,b=1>b||b>30?30:

Change it to something like 300 to extend Hearbeat requests out to 5 minutes:

case 300:...300,b=1>b||b>300?300:

60 Second requests

To extend the behavior of having a Heartbeat request every 60 seconds, you would look for this code:

B.mainInterval>60&&(B.mainInterval=60))...case 60:...mainInterval:60

Change it to something like 600 to extend Hearbeat requests out to 10 minutes:

B.mainInterval>600&&(B.mainInterval=600))...case 600:...mainInterval:600

You should now hopefully understand what the WordPress Heartbeat API is, and how you can control it in the event it's causing too many requests to your admin-ajax.php script.

Did you find this article helpful?

We value your feedback!

Why was this article not helpful? (Check all that apply)
The article is too difficult or too technical to follow.
There is a step or detail missing from the instructions.
The information is incorrect or out-of-date.
It does not resolve the question/problem I have.
How did you find this article?
Please tell us how we can improve this article:
Email Address
Name

new! - Enter your name and email address above and we will post your feedback in the comments on this page!

Related Questions

Here are a few questions related to this article that our customers have asked:
Ooops! It looks like there are no questions about this page.
Would you like to ask a question about this page? If so, click the button below!
Ask a Question
n/a Points
2014-04-03 4:49 am

Thanks a lot for sharing mate - gr8 explenation!

this helped me deal with Hostgator contantly telling me i am overusing the cpu ;)

keep up the great work

Staff
9,968 Points
2014-04-04 1:53 pm
No problem at all! Thanks for commenting and letting me know it's helping people out :)

- Jacob
n/a Points
2014-04-05 6:46 am

This broke my website.. http://www.kheuning.nl/moustache/

 

Staff
18,017 Points
2014-04-06 9:28 pm
Hello Jonas,

If you can give any specific errors messages or describe the error we are happy to see if we can assist you.

Kindest Regards,
Scott M
n/a Points
2014-04-14 1:02 pm

I was little confused, my site was taking over 6 seconds to load. Pingdom said, its admin-ajax.php thats taking most of the time.

In mean while, I got to this post and it helped me reduce over 3 seconds of load time !!

Nice post, Good work !! Keep posting

Kindest Regards

Anirudh Babbar

http://thinkncode.com

Staff
9,968 Points
2014-04-14 3:04 pm
Hello Anirudh,

I'm really glad to hear that this article helped your reduce your WordPress load time! I wrote another general optimize WordPress guide that you might want to glance over as well to reduce your load time even further.

For instance it looks like you could use a WordPress caching plugin to speed up WordPress.

I would also recommend testing your site on GTmetrix.com. One thing of note slowing down your loading times is that you have quite a few images that are of a decent size like 580x390 that are then being resized in HTML or CSS down to 220x148. It looks like if you just resized those images into the size they were going to be used on the site, you could save close to 1MB worth of downloads for your page to fully display.

- Jacob
n/a Points
2014-04-16 6:49 pm

Hmm, I've had a lot of trouble from this, trying to figure out why my javascript stopped working in the backend of WP. After I inserted the script, my buttons, e.g. "Add a category" stopped working properly, I couldn't click on them. 

However, after I removed this script, everything works fine!

Not sure how heartbeat works, but on my installation of Wordpress, I don't see any significant difference in speed when I disable it. Still, good to know...

Staff
9,968 Points
2014-04-16 7:07 pm
Hey Nick, and thanks for the comment.

I'm not sure why JavaScript would have stopped functioning for you by just disabling the Heartbeats. Which of the particular methods did you use, or did you try them all?

If you're not noticing a lot of requests for your admin-ajax.php script in your website access logs, or not noticing high CPU usage from your WordPress site I wouldn't worry about disabling them. This guide is more or less for people that are noticing issues with the Heartbeats and looking to squeeze a little more performance out of WordPress.

If you'd like to provide any details for your site here, feel free to comment and we can remove any private information before approving the comment to go public so we can help you troubleshoot if you're interested.

- Jacob
n/a Points
2014-04-19 11:21 am

Hey, thanks for the offer. Yeah, I guess it was quite pointless for me to disable heartbeat, as my WP installation was running (relatively) fast before. And plus I use a good hosting provider - DigitalOcean. They are very good, no bloatware, no server control panels - developer heaven =)

Oh, and the code I used to disable heartbeat was the first one, i.e. to disable it everywhere.

n/a Points
2014-05-05 1:30 pm

Hi.

Thanks for posting this fix.  However, I have the same problem - the first fix disabled buttons and whatnot on my admin pages.  Specifically:

- edit link

- edit published state

and more on edit page/post.

It also disabled buttons on page lists.

I am using Avada with a child theme on Hostgator.  I disabled my other plugins.  Still have problems.

Any ideas?

Thanks,

--Will

Staff
16,565 Points
2014-05-05 2:16 pm
Hello Will,

Sorry to hear that you're having problems with the fix presented by Jacob. I noticed that you said you had problems with the first fix. As this issue may be related to the theme, have you tried removing the fix, and then using the dashboard only solution? Please let us know if you are able to do this and the results of this action. If you continue to have problems, please provide some further information on the issue.

Kindest regards,
Arnel c.
n/a Points
2014-05-12 4:19 pm

Hi, Arn.

Thanks for your response.  Yes, I think it was probably a theme conflict.  I ended up using the more specific "Disable Heartbeat everywhere except post.php and post-new.php"  Though, I'd prefer to shut the thing off everywhere - my host shut my site down without any notification.  It was a beta site at the time, so it wasn't a big deal, but if that had been a live site I would have been in trouble.  

Anyway, I'm now trying to make sure I don't have too many admin windows open at the same time.  So far I haven't had further issues.

--Will

 

n/a Points
2014-04-20 5:27 am

Thanks for this great article.

To disable the Heartbeat API doesn´t work for me. I just updated the function.php in my theme root folder, but I have still the same problem. Any Idea?

My Website is www.roland-steinmassl.com

Thanks a lot,

Roland

Staff
8,314 Points
2014-04-21 8:46 am
As long as the additional lines are in place, the heartbeat calls should stop. If you are still seeing it, try disabling any caching plugins that you may have as well as clearing your browser cache as this could cause them to keep coming.
n/a Points
2014-04-21 4:25 pm
Hey Jeff. Thanks for your quick response. I have no caching activated, it is just pagespeed mod @ apache active. It is strange because i can´t disable the heartbeat. The error occurs when i am activating woocommerce or slim stat. :/ I disabled all Plugins and reacivated all until i found 2 Plugins which are not compatible with the Heartbeat. It is for sure: "Woo Coomerce" and "Slim Stat" - Both are very important for my site, but unfortunatly, activating them the pagesspeed goes up from 1,5- 2 seconds to 7-10 seconds. The Heartbeat is a really annoying and frustrating feature - They should call it bug. Any Ideas?
Staff
9,968 Points
2014-04-21 5:02 pm
Hello Roland,

Which method are you using to attempt to disable the Heartbeats? Also how are you testing to see if the Heartbeat API is disabled after adding the function to your functions.php script?

Typically you would SSH into your server and tail your access logs with a command like this:

tail -f ~userna5/access-logs/example.com | grep admin-ajax.php


If the Heartbeat is still active, you would typically see requests for your /wp-admin/admin-ajax.php script, coming from your WordPress dashboard at /wp-admin/index.php again and again while you're logged in.

I agree that the Heartbeat feature can be annoying, I've personally commented on a WordPress.org TRAC ticket for HeartBeat 2 months ago and haven't received a respond back from any developers. From a system admin side instead of a developer's outlook, the feature is too aggressive by default and could be prone to issues.

Unfortunately the only work around for the time being is to disable it. I'm wondering if possibly one of those 2 plugins that you mentioned is overriding your theme's disabling of the Heartbeats and turning it back on. You might want to reach out to those plugin developer's and let them know of the issues you're experiencing.

- Jacob
n/a Points
2014-04-22 2:09 pm

As a host I don't usually like linking to other hosts articles, but this is so well articulated I am happy to. Much appreciated.

Staff
9,968 Points
2014-04-22 2:27 pm
Hey PipeTen,

Thanks for the kind words! Always love to help out the hosting community in general, so glad you found the info helpful!

- Jacob
n/a Points
2014-04-28 12:47 am

This article saved me with Hostgator. Thank you so much.

Staff
9,968 Points
2014-04-28 3:01 pm
Hello SGD,

Glad to hear it helped you out! That was my purpose in writing this article, to try to save others the headaches I went through when I first found out about these issues.

- Jacob
n/a Points
2014-05-01 2:10 am

Hey Jacob. it doesn't work for me. I tried the 3 codes but i still see a huge load time (about 2.4 sec) only for "admin-ajax.php"

Please test my site "http://tools.pingdom.com/fpt/#!/XRv8v/www.elhafez.com"

I got a great score actually (99) with load time bwteen 2.5 - 3.5 sec and almost all wait time caused by admin-ajax.php.

Any suggestions please

Thank you

Staff
8,314 Points
2014-05-01 7:56 am
We have tested to ensure that the code works correctly. Be sure that you have placed it within your active theme's functions.php file or have created a child theme with this located within it. If you're still seeing the issues, you may have another environmental variable that is causing it. Unfortunately, as the site you are referencing is not hosted with us, I am unable to look further into it, but contacting your host may provide more insight.
n/a Points
2014-05-01 11:26 am

Thanks for reply, indeed it was caused by woocommerce and i followed this "http://wordimpress.com/how-to-load-woocommerce-scripts-and-styles-only-in-shop/#comment-1363608585" tutorial and the issue finally fixed.

Thank you

Staff
16,565 Points
2014-05-05 2:13 pm
Hello elHafez,
You're welcome! Thanks for your patience and persistence! Let us know if you have any further questions.

Regards,
Arnel C.
n/a Points
2014-05-10 2:55 pm

Thank you for this.

My admin-ajax.php was slowing the site by 4.2 secs. After adding the code to my functions PHP admin-ajax.php only take s up 1.45 secs. I find tools.pingdom.com requires at least 15 secs wait to give a good reading between tests.

 

Thank you very much for this

Staff
18,017 Points
2014-05-10 11:53 pm
Hello Jim,

You are most welcome! Please let us know if you run across any further questions or issues. We are always happy to help.

Kindest Regards,
Scott M
n/a Points
2014-05-12 12:01 pm

Update on my last comment. Even better now. Total site load time now down to 1.52secs with only a 920ms load for admin-ajax.php after adding you code to my theme functions.php :)

 

Thanks again

Staff
16,565 Points
2014-05-12 12:59 pm
Hello Jim,

Thanks for letting us know how it turned out! If you have any further questions or comments please let us know by submitting a post on the Community Support Center website.

Regards,
Arnel C.
n/a Points
2014-05-19 10:45 pm

Recently i recieved a message from my host about heavy admin-ajax.php usage and i arrived here through Google. But after applying the "Disable WordPress Heartbeat everywhere" I can't add tags to my post any more, it seems to have disabled the feature. What can i do?

Staff
8,314 Points
2014-05-20 8:38 am
My best guess is that you overwrote something within your functions.php file that caused this. I recommend restoring your theme's functions.php file from backup and making this change again to the bottom of the page, ensuring that noting is overwritten.
n/a Points
2014-07-31 11:00 pm

Hi...

I also have the same problem, I can't add tag after inserting the code. Do you mean try to insert the code at the bottom of the functions.php file?

Staff
9,968 Points
2014-08-01 12:04 am
Hello Joseph,

Multiple comments have been submitted about these type of broken features that rely on the WordPress Heartbeat API to function. As it mentions in the article, it's not recommended to disable the WordPress Heartbeat API unless you're having CPU usage issues with your WordPress install.

If you are having CPU usage issues you can leave the Heartbeat API left on for certain pages that seam to lose functionality with it disabled everywhere.

For instance if you're in the edit post page and can't add tags, you should notice the URL in your web-browser is calling the post.php script. So you can simply detect if WordPress has that script opened, and if so don't disable the Heartbeat API. But still go ahead and disable it everywhere else to save on resources:

add_action( 'init', 'stop_heartbeat', 1 );

function stop_heartbeat() {
global $pagenow;

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



Please let us know if you had any other questions at all.

- Jacob
n/a Points
2014-06-10 3:03 pm
HeartBeat API is good but it also has some bugs. My website has suffered a lot because of this bugs. I have written an article on the same http://www.outscream.com/heartbeat-api-the-heart-of-wordpress/
Staff
9,968 Points
2014-06-10 3:18 pm
Hello Manoranjan,

You are right the WordPress Heartbeat API can be intensive sometimes. You might want to double-check the code in your article for disabling it. It looks like you've also included some HTML <br> tags in the PHP code itself, if someone were to place that code into their WordPress functions.php script it could break their site.

- Jacob
n/a Points
2014-06-13 7:56 am

I wish HostGator Support came here and saw this.

Those clowns have suspended one of my sites twice in the last 24 Hours and their support sucks.

Have a feeling the CPU/Resource problem maybe due to the above.

Feel free to email me a discount coupon as I think it is time I changed hosts.

Staff
9,968 Points
2014-06-13 6:51 pm
Hello Asif,

Sorry to hear about your CPU resource usage issues with your current host. You might not just be having problems with the WordPress Heartbeat API and might also want to check out my guide on how to optimize WordPress to make sure it's not also something else.

I've gone ahead and also emailed you a coupon code as requested. If you happen to sign-up, let us know!

If you had any other questions at all, feel free to ask!

- Jacob
n/a Points
2014-06-13 7:44 pm

Thanks for the coupon and the Guide.

I was thinking of opening a PRO account, do you have a coupon for that?

Anyway I am already very impressed.

Staff
8,314 Points
2014-06-16 8:33 am
I'm not sure which coupon code Jacob sent you, but most coupons should work with shared hosting. Coupons can sometimes also be found with a simple Google search as well.
n/a Points
2014-06-13 5:11 pm

Hello,

Highly appreciate your efforts, was driven here by Google after I've got a warnning regarding CPU Usage caused by admin ajax...

Just one simple Q.

I am using another theme but what you have mentioned, I added the code to the bottom, just before ?>

So is that OKay or it must be added to a specific line!

Thanks in advance.

Staff
16,565 Points
2014-06-13 5:34 pm
Hello Jack,

Jacob's recommendation advised finding the functions.php file for your theme and then adding the code to the top. I would keep the code at the top just so that it takes precedence over any code that is already in that file.

I hope that helps to clarify the issue. Please let us know if you have any further questions.

Regards,
Arnel C.
n/a Points
2014-06-13 7:19 pm

Thanks for your quick response and the explanation as well, highly appreciated

I've moved the code from bottom and now it is located right after the <?php

So is this the right place to be!

Thanks in advance.

n/a Points
2014-06-14 1:42 pm

Hello, Arn

I've used the 3rd code everywhere but posts and it works fine, However; the admin ajax still using 40% of CPU and about 1.8% of memory!

Staff
18,017 Points
2014-06-15 8:02 am
Hello Jack,

Be sure to also take a look at our article on optimizing WordPress and see if that also helps the resource usage for your site.

Kindest Regards,
Scott M
n/a Points
2014-06-15 5:35 pm

Hello Scott,Despite the modifications I've done on the last few weeks, but the link you gave is really a life saver :)Thanks for your quick response and highly appreciate your guidance as well

n/a Points
2014-06-14 8:48 am

Great tip, thanks for sharing! Here's a tip back.

Instead of editing the theme's functions.php file, use the Code Snippets plugin instead. I'm in no way affiliated with the plugin, just a user. I've found that it is great for adding the random action/filters I find around the web. Using it there's less of a chance of breaking something. Here's the link:

https://wordpress.org/plugins/code-snippets/

n/a Points
2014-06-19 6:27 am

In my functions.php I see following code:

<?php\\one functions is here

?>

 

so where should I put your code?

above <?php ?

or below <?php ?

 

 

Staff
9,968 Points
2014-06-19 7:31 am
Hello Vijay,

You'd want to place the code below the <?php opening tag. There can be multiple functions in this file as long as they don't overlap each others code.

Please let us know if you had any other questions.

- Jacob
n/a Points
2014-06-19 8:54 am

Hi,

Thanks for you code. I put this code as a must use plugin and it seems to do its job fine. The only trouble I'm facing now is that the Quick Edit functionality on the posts / pages screen don't seem to work anymore. I did however find that the wp-admin js "inline-edit-posts.js" also seem to be deregistered when I view the source, and I'm not sure why. Any thoughts? Thanks.

Best,

A

Staff
8,314 Points
2014-06-19 9:22 am
These code snippets should not affect your Quick Edit functionality at all. Be sure that in the process of editing your functions.php file, you did not overwrite anything important.
n/a Points
2014-06-19 9:32 am

Hi, Thanks for your response.

As I have mentioned earlier, I did not put this code in my functions.php file. I created a new "must use" plugin under the "mu-plugins" folder and put the code in a file over there so that it is always used. But for some reason, it seems to deregister the other wp-admin js file too.

Thanks & Best,

Andy

Staff
8,314 Points
2014-06-19 9:40 am
Is this the only thing within the plugins folder? Perhaps something else is in there that is overriding existing functions?
n/a Points
2014-06-19 10:23 am

This is the only one inside the mu-plugin folder. If I comment the "add_action( 'init', 'stop_heartbeat', 1 );", the quickedit seems to work fine. Am pretty sure that something is working along with the heartbeat that is messing things up, but still haven't found what it is. Thanks for your help.

Staff
9,968 Points
2014-06-23 6:30 pm
Hello Andy,

If disabling the Heartbeat API is causing the quick edit to not work, and you'd still like to disable it for the most part. You could disable Heartbeat everywhere except on post.php and post-new.php as mentioned in the last example above, except use edit.php instead like this:

add_action( 'init', 'stop_heartbeat', 1 );

function stop_heartbeat() {
global $pagenow;

if ( $pagenow != 'edit.php' )
wp_deregister_script('heartbeat');
}


That should leave the Heartbeat API on when using quick edit, but keep it turned off everywhere else where it isn't causing any problems being disabled.

- Jacob
n/a Points
2014-06-21 12:22 pm

Hi there,

really nice article! I still having the same problem on my webshop www.filamentworld.de.

I've allready tried all of your workarounds, with no success. No change at all. I would be really grateful if you'll have a look at the site.

Best,

Robin

Staff
16,565 Points
2014-06-23 1:04 pm
Hello Robin,

Sorry to hear about the problems with the WordPress site. As your site is not hosted through us, we have no way of directly accessing your files and see the changes how they're affecting (or not affecting) your server. If you are experiencing performance issues with WordPress there are many possible causes. Make sure that you have optimized WordPress as well. If you continue to have issues after optimizing the site, then please reply here, and indicate the URL where you are seeing the problem. The URL for the main site does not appear to be having performance issues when we view it here (in Virginia).

Regards,
Arnel C.
n/a Points
2014-06-24 8:19 pm

Thanks Jacob, I disabled Heartbeat for all admin pages and my website http://bc25.com is fast again! The extra ajax calls on this site and few other WP sites I run on the same server were realy slowing everything down and using swap memory.

Really appreciate your suggestion.

Staff
9,968 Points
2014-06-25 4:54 pm
Hello Mike,

No problem at all, glad to hear this suggestion helped speed things up for you. Now keep in mind that the Heartbeat API is typically only used while logged into the WordPress dashboard. So you might also wish to optimize WordPress in general to really get things going as fast as possible.

- Jacob
n/a Points
2014-07-02 8:57 pm

Thank you dashboard code fixed it perfectly!!!

Question: Quick Edit doesn't work after Heartbeat disabled

n/a Points
2014-07-14 8:43 pm

I just changed my site over to WP and working day and night on design and got an email from your techs saying I was over using the server...and suggested I add this code to my /theme/functions.php, which I did... and then the "Quick Edit" link and edit the publish date/time link were both dead.&; Click on them and nothing...

Here is the code I entered...

add_action( 'init', 'stop_heartbeat', 1 );

function stop_heartbeat() {
wp_deregister_script('heartbeat');}

at the top right below:

* @since presscore 0.1

I just changed the functions.php back to the original and those links are working again. I want to kill the heartbeat thing but dont want to disable other things...so what should I do ?

Staff
9,968 Points
2014-07-14 11:26 pm

Hello Paul, and thanks for your comment.

If you're having issues with the Quick Edit link after disabling the WordPress Heartbeat API everywhere, I'd recommend either using the normal edit page, or you should be able to use the same steps as mentioned in this guide to disable Heartbeat everywhere except on post.php and post-new.php, just use edit.php instead:

This goes in your /wp-content/themes/THEME_NAME/functions.php file


add_action( 'init', 'stop_heartbeat', 1 );

function stop_heartbeat() {
global $pagenow;

if ( $pagenow != 'edit.php' )
wp_deregister_script('heartbeat');
}



Also I'd be sure to log out of the WordPress dashboard when not in use and to follow some of the basic steps to optimize WordPress.

As always you can view CPU usage graphs in cPanel to see the positive affect any of your optimizations are having.

Please let us know if you had any other questions at all!

- Jacob
n/a Points
2014-07-15 8:43 am

Thanks Jacob.

Well I can use the edit page instead of Quick Edit...but I still need to be able to edit the publish date/time sometimes...and that code killed that when I did it in theme/functions.php. 

I will try this new code in the edit.php file....is that the edit under /wp-admin/edit.php ?

And for logging in and out... since I am just designing the site, and LEARNING as I go, I am logging in and staying working on things ALL DAY and much of the night (work-a-holic) so I have to be logged in...so not sure how I can fix that.  Once I get the design where I want it, and things working right, I will not be logging in much at all I guess.

Thanks

Paul

n/a Points
2014-07-15 10:55 am

Hi Paul,

I had the same issue and was able to resolve it by making the following changes.

Change your function in the /theme/functions.php file to below:

function stop_heartbeat() {
global $pagenow;
if ( $pagenow != 'post.php' && $pagenow != 'post-new.php')
wp_deregister_script('heartbeat');
wp_register_script('heartbeat', <path_to_js>."/dummy.js" );
}

Please create an empty file dummy.js file in the <path_to_js> folder.

Basically, quickedit.js file seems to depend on heartbeat and hence, de-registering heartbeat disables it. This way, when we register heartbeat again as an empty file, atleast quickedit seems to work. Please try if the above works for you. Thanks.

Best,

Andy

n/a Points
2014-07-15 11:32 am

Thanks Andy.

Being a novice...this scares me because I am not sure I will copy the code correctly since I know spacing, blanks, etc.. are crucial in php talk.  Can I just create a dummy.js file in a text editor ?  In other words, open a text editor and save a blank doc as "dummy.js" ?  I can just throw it in the root directory I guess.

You would think (as a beginner I think this) that Wordpress core files would give you options in admin to turn all this stuff on and off...since its so crucial.  Maybe that is why there are hundreds and thousands of plugins for the same things.  Redundent, inefficient and confusing !!      

As for Hosting Companies... if I were you, I would create a core set of plugins and steps to configure CPU usage, search bots, cache, autosaves, etc..  in (1) file or tutorial for a begginer like me to go straight to and configure as YOU SAY.  This would save YOU guys a ton of support time and lots of stress on both sides.  I am having to try to read and understand on my own and alot of it is contradictary.  One person or place says to handle a situation this way, and the next person says something totally different.

Staff
16,565 Points
2014-07-15 12:39 pm
Hello Paul,

The change must occur within the specified file above. Making a separate file labeled "dummy.js" will not work. When following the directions, you would be making a backup of the file first, so that if there were any problems, it would be easy to restore from the backup.

Also, in regards to a plugin, when you do a standard installation for WordPress, there are no specific settings that need to be put into the WordPress entries for default installations. Here are some references in our support center for installing WordPress that describe the settings that are seen during the setup process:


Regards,
Arnel C.
n/a Points
2014-07-15 1:03 pm

Hi Arn,

Hope all is well. I do believe just creating a file called dummy.js in the theme directory (eg) and adding the function below in the theme functions.php file would do:

add_action( 'init', 'stop_heartbeat', 1 );
function stop_heartbeat() {
global $pagenow;
if ( $pagenow != 'post.php' && $pagenow != 'post-new.php' )
wp_deregister_script('heartbeat');
wp_register_script('heartbeat', get_bloginfo('url') . "/dummy.js" );
}

get_bloginfo('url') pulls from your WordPress root directory

get_bloginfo('template_url') pulls from your WordPress theme directory

I had the same issue on few of my sites and this seemed to solve my problem. I did go thro the load-scripts.php file to find that quickedit.js was dependent on heartbeat. Pls let me know if I'm wrong. Thanks.

Best, Andy

n/a Points
2014-07-15 2:15 pm

Jacob, I just added the code you have to the wp-admin/edit.php and got an error when I clicked on posts and pages....

Fatal error: Call to undefined function add_action() in /public_html/wp-admin/edit.php on line 8

I copied and pasted from your reply, but something is wrong.

See, Arnel and Andy you guys are proving my point... so much confusion especially to newbies who dont understand most of what you are saying anyway.  If the heartbeat issue is such a huge issue to all servers and usage, etc.. then it would make sense for that to be in the core admin to configure it, turn it on and off, etc..  

Staff
9,968 Points
2014-07-15 3:27 pm
Hi Paul, and Andy, thanks for your responses!

The code I mentioned above for the edit.php file still would go into the /wp-content/themes/twentyfourteen/functions.php folder, or the one of your particular theme. As it still disables the Heartbeat API, but not for edit.php script which is what Quick Edit uses. When you click on Posts in WordPress it uses the edit.php script.

Be cautioned that doing this will still cause Heartbeat requests from that particular Posts page:

[15/Jul/2014:13:26:48 -0400] "POST /wordpress/wp-admin/admin-ajax.php "http://example.com/wordpress/wp-admin/edit.php"
[15/Jul/2014:13:28:48 -0400] "POST /wordpress/wp-admin/admin-ajax.php "http://example.com/wordpress/wp-admin/edit.php"
[15/Jul/2014:13:30:48 -0400] "POST /wordpress/wp-admin/admin-ajax.php "http://example.com/wordpress/wp-admin/edit.php"
[15/Jul/2014:13:31:39 -0400] "POST /wordpress/wp-admin/admin-ajax.php "http://example.com/wordpress/wp-admin/edit.php"
[15/Jul/2014:13:31:54 -0400] "POST /wordpress/wp-admin/admin-ajax.php "http://example.com/wordpress/wp-admin/edit.php"



But, when you go anywhere else in the Dashboard it won't use Heartbeat requests. Just make sure not to leave open the Posts page as you're making your modications, so it doesn't sit in the background for long times using up CPU resources from your account.

You can also use the Edit link instead of Quick Edit when you have Heartbeat requests disabled for every page. On the right under the Publish section you should see Publihsed on: and you can click Edit there to modifiy the publish date/time.

I agree that us as webhosts could provide easier functionality for some of this stuff and I've recently gotten into WordPress plugin development myself after writing about how to create your first WordPress plugin. So hopefully we will have some plugins for our guides that easily lets you modify these types of things in the near future. It's important to note that these types of issues happen for a very small percentage of users, and we are only human so we try to prioritize needs as best we can.

I can relate to the up all night workaholic and staying logged into WordPress all the time as you're learning, and by the way I love your site design so far and the photo gallery is a really cool feature. Just be mindful that while on a shared hosting package it's not directly intended as a development enviornment like a Virtual Private Server would be. It's more geared towards serving up the website where things like caching and database optimizations can efficiently serve your website and have your CPU usage coincide with all the other shared hosting customers on your server.

A lot of development work and refreshing of non-cached pages and admin requests can lead to a lot of CPU usage unfortuantely, and that's why I initially wrote this guide to try to help lessen the impact of staying logged into the dashboard. Just keep an eye on your CPU graphs on late night coding sessions and if you notice you're spiking too high too quickly, possibly try to scale back or do some development work locally. For instance for design and CSS I like to just use Google Chrome and the Inspect Element (Ctrl-Shift-C) to edit things on the fly locally and once I have some settings I like I fire up WordPress and just copy them over. For development I use Sublime Text and just FTP up my files to the server to avoid additional website requests.

Thanks a lot for adding a suggestion Andy, I took a look at it and it does indeed appear your code should allow the Quick Edit to continue to function while Heartbeat requests are disabled.

Sorry for the confusion from the response by Arnel, I think he was just referring to that method of disabling the Heartbeat API seems to do the same thing as just including edit.php into the if ( $pagenow ) statement:

add_action( 'init', 'stop_heartbeat', 1 );

function stop_heartbeat() {
global $pagenow;

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



However it seems that with your method there is the added benefit that you can still be on the edit.php Posts page and still use Quick Edit and you don't have to leave the full Heartbeat script enabled for it to work since you're just loading up the dummy one which doesn't send Heartbeat requests.

It's important to note that when using the the get_bloginfo('url') . "/dummy.js" method of calling your dummy.js file, it needs to be placed in your WordPress root directory.

You can use get_bloginfo('template_url') . "/dummy.js" instead to make it your theme directory where you're editing the functions.php file.

Thanks again to both of you for your comments and suggestions. I'll make sure that this guide continues to get updated to reflect the best methods for disabling the WordPress Heartbeat API easily.

- Jacob
n/a Points
2014-07-15 3:56 pm

Thanks Jacob.... but the more you guys write, the more confused I get. You code people have to remember, not everyone understand 10% of what you are saying...which is why I want a "button" that says "fix heartbeat" in the admin section for newbies like me.

I just added the :

add_action( 'init', 'stop_heartbeat', 1 );

function stop_heartbeat() {
  global $pagenow;
  if ( $pagenow != 'edit.php' )
  wp_deregister_script('heartbeat');
}

into the theme/functions.php and tested...and the posts lists come up, and the "Quick Edit" now comes up, but when I actually edit the post and click on the "edit" publish date/time...nothing opens still. So that is still dead. I guess its not THAT important so I will hush and move on... at least the heartbeat is dead like you guys want so that is good. I will just have to be careful and not publish until I am ready since I cant change that later now.

Staff
9,968 Points
2014-07-15 4:24 pm
Hello Paul, you're welcome.

I'm not a coder either but a system administrator and agree that WordPress should come with a way to disable this feature by the user by default. Again needing to disable this feature in Wordpress can break WordPress functionality as is mentioned in the red alert box under the Disable WordPress Heartbeat API section of this guide. We can look closer at a plugin for our own customers to more easily implement these functions automatically, but there is a lot more that goes into that than meets the eye at first.

I mainly put this guide together to help users around the resource usage issues pertaining to admin-ajax.php and to a certain extent you do kind of want to understand exactly what you're doing, because depending on the particular WordPress Themes or Plugins you are using or the type of workflow you have in the admin dashboard these steps disable a default WordPress feature. You're using over 20 plugins and one of them for instance might need to use Heartbeat requests.

With the code that you're using it's only doing it for the edit.php page. When you are actually on the post itself that is the post.php page as you can tell by the URL in the browser you'd need to exclude that page as well to use the normal Edit button:

add_action( 'init', 'stop_heartbeat', 1 );

function stop_heartbeat() {
global $pagenow;

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



Again though you'd want to stay aware that while on any of those 3 pages post.php, post-new.php, or edit.php, that Heartbeat requests would be getting used in the background so you wouldn't just want to leave those pages open for long periods of time, especially when you aren't doing anything in them.

- Jacob
n/a Points
2014-07-15 5:01 pm

OK Jacob, just to get straight...  Now that I have entered the

add_action( 'init', 'stop_heartbeat', 1 );

function stop_heartbeat() {
global $pagenow;

if ( $pagenow != 'edit.php' )
  wp_deregister_script('heartbeat');
}

in the functions.php file...; Do I still need to be watching the "clock" when I am editing a "post" and/or "page" ? So the server CPU is crunching when I am "editing" one of those ? Is it "idle" when I am just in dashboard or plugins, or contacts, etc... I am trying to be a good boy listening to your Sys Admin folks and keep that CPU chillin.

Staff
9,968 Points
2014-07-15 5:47 pm
Hello Paul,

With that code, you are basically telling WordPress, on any page other than edit.php disable the WordPress Heartbeat API.

It's saying if $pagenow or the current page you're on, is not equal to != the edit.php page, then deactivate the Heartbeat requests.

So you would want to keep an eye on your CPU usage if you're staying on that Posts page where you see edit.php in the URL. But if you're on the post.php or post-new.php pages it won't be using the Heartbeat requests so you shouldn't have to worry about staying on those pages for long times. But note that because you've disabled the Heartbeat requests for those pages, things like auto-saving won't take place, so keep that in mind before you go type a really long post and then accidentally close the tab.

You can use the same steps in my review WordPress login attempts guide and use the Latest Vistors cPanel plugin under the Logs section to verify Heartbeat requests have stopped. Just type in /wp-admin/admin-ajax.php into the search field instead, and I'd recommend clicking the settings cog at the top-right and selecting Time, URL, and Referring URL to see where the most requests are coming from.

I appreciate you working to understand and implement a workaround that will keep your account's CPU usage at normal levels, and I'll be sure to continue to look for easier ways for our customers to implement changes like this.

- Jacob
n/a Points
2014-07-25 10:18 am

I think ever since I added the heartbeat code to kill that, when I am in "Edit Post" the permalink edit is dead, wont let me edit it.  I am seeing that url is not titled correctly althought that page is coming up fine, so am trying to correct the permalink to that post page but it wont let me edit it. 

Also notice when you are in the "Edit Post" the edit the publish date/time wont work either.  You can edit the date/time from the "Quick Edit" but not once you are inside the post itself.  That was also after the Heartbeat code was added. 

Staff
9,968 Points
2014-07-25 2:39 pm
Hello Paul,

Are you sure you need to be disabling the WordPress Heartbeat API for your site?

Again the WordPress Heartbeat API is an advanced default feature of WordPress that isn't supposed to be disabled. It should only affect performance when logged into the WordPress admin for long periods of time. If there are certain features that aren't working for you within the dashboard when you're disabling it and you don't quite understand the under workings of what's going on, it might be advisable to just leave it active.

In this case, when you're on the Edit page of a post, you'll notice in the address bar that it's using post.php. If you're using the code above, like I explained that would disable the WordPress Heartbeat API everywhere except for edit.php, so that's why you can't edit the Permalinks or Published date.

You could exclude both pages:

add_action( 'init', 'stop_heartbeat', 1 );

function stop_heartbeat() {
global $pagenow;

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



If you are editing your post outside of the WordPress admin and then just paste it into your post, so you're only in there for a few moments as you update the Permalinks or edit the date you can also minimize the impact the Heartbeat API has on your CPU usage if you just leave it on.

Another alternative would be to store two copies of your functions.php file with one named something like functions.php-HB-ON, and one as functions.php-HB-OFF. Then when you need to do something that required the Heartbeat API just copy the HB-ON file over the original functions.php file, and to turn it back off copy the HB-OFF one on top containing the code to disable the Heartbeat.

Hope that helps.

- Jacob
n/a Points
2014-07-22 4:16 pm

Hi! :)

Thank you for this blog, it is very useful :)

I have a question though, I want to use this function to reduce page load but I am using buddypress and with this code in my functions.php a lot of buddypress features are not working anymore (such as load more button on activities, delete button...)

 

How can I enable this code everywhere but on buddypress pages?

thank you a lot! :)

And keep up the good work!

Staff
9,968 Points
2014-07-22 7:30 pm
Hello Estellya, and thanks for your comment.

Can you please be a bit more specific about how you are going about disabling the Heartbeat API in WordPress, and how you are getting to the BuddyPress functions that no longer seem to be working after disabling the Heartbeat API?

At the bottom of this guide I have given 3 examples for how you can either disable or leave the Heartbeat API on for certain pages. If you see a feature isn't working on a plugin, then you should be able to look up into your address bar and see the page that you're on.

For instance, if you're just at the main WordPress dashboard, you'll see the page you're on is index.php. So if you wanted to disable the Heartbeat API just there you'd use this in your functions.php file:

add_action( 'init', 'stop_heartbeat', 1 );

function stop_heartbeat() {
global $pagenow;

if ( $pagenow == 'index.php' )
wp_deregister_script('heartbeat');
}



That line with $pagenow == 'index.php' is stating that if the current page you're on just says index.php then run the wp_deregister_script line right below it and turn off the Heartbeat API.

If you were having some problems when navigating in the WordPress admin dashboard to Settings > BuddyPress and clicking on the Pages tab for example. You should notice that the URL reads:

admin.php?page=bp-page-settings

So if you wanted to leave the Heartbeat API enabled on that one particular page, but disabled everywhere else you could use this:

add_action( 'init', 'stop_heartbeat', 1 );

function stop_heartbeat() {
if ( $_GET['page'] != 'bp-page-settings' )
wp_deregister_script('heartbeat');
}



In this case we are checking the $_GET['page'] variable that is part of the URL, and if it is not equal != to our page of bp-page-settings, we disable the Heartbeat API. While if you're on that page itself, it will still use the Heartbeat API if for some reason certain functions of a plugin don't work with it disabled.

Again if you can be specific as possible as to what you're seeing and how you're getting there, we'd be glad to take another look and see if you might need to use some other settings to get things to work the way you want.

Please let us know if you had any further questions at all!

- Jacob
n/a Points
2014-07-23 2:23 am

Hello, thank you for your answer! :)

I noticed that some buddypress features are not working with this code because when I add it to my functions.php it is not working, and when I remove the code it is working again, so I supposed it comes from it... well can't explain more really ^^

On a buddypress group page, there is the group activity feed, and when I want to load more comments and activities (with the "load more" button at the bottom of the page) nothing happened and so nothing load with the code, when I remove  the code it is working again.

Ok, yes I have read the part where you say how to disable it on certain pages but I thought it was only for pages with an actual .php name like index.php and when I am on a buddypress group page it is just the group name in my address bar it is not a file so I was not really sure what "page" I should add. (I am a real newbie with all of this sorry :/)

 

I will try to fix this thank you for your help sorry for bothering and my bad english ^^

Thanks!

Staff
9,968 Points
2014-07-25 4:50 pm
Hello Estellya,

You are going to need to be more specific with your problem so that we can offer you the best solution. If possible always try to include the exact URL you're trying to go to, the steps you're following to end up at a problem, and the code you're using to attempt to disable the Heartbeat API. Otherwise we are kind of just guessing at what you might be doing.

I installed BuddyPress to try to recreate your scenario, but even after leaving a bunch of comments on a group I didn't see a Load More button appear for the comments in the activity stream.

However all the other buttons on the group activity page Comment, Favorite, and Delete seem to still function.

You might want to leave the Heartbeat API enabled except on specific admin pages as I mentioned before. That way it stays on for your BuddyPress pages, but off for the common pages like the admin dashboard at index.php or the edit post page at post.php:

add_action( 'init', 'stop_heartbeat', 1 );

function stop_heartbeat() {
global $pagenow;

if ( $pagenow == 'index.php' || $pagenow == 'post.php' )
wp_deregister_script('heartbeat');
}



If you're still getting a lot of activity to the /wp-admin/admin-ajax.php script from people sitting on your BuddyPress pages. I've discovered you can also go in and edit the Heartbeat API JavaScript file directly and increase the time in between requests.

You could edit this file after making a backup of the original:

/wp-includes/js/heartbeat.min.js

There are several sections where it setups the default behavior for the Heartbeats, one for the default of 15 seconds, one for 30 seconds, and one for 60 seconds. I changed them all to over 120 seconds or 2 minutes in between requests, and sure enough this slowed down the Heartbeat requests.

15 second default

B.mainInterval<15?B.mainInterval=15
case 15:

Changed to:

B.mainInterval<120?B.mainInterval=120
case 120:

30 second delay

case 30
30,b=1>b||b>30?30:b

Changed to:

case 121
121,b=1>b||b>121?121:b

60 second delay

B.mainInterval>60&&(B.mainInterval=60))
case 60:
mainInterval:60

Changed to:

B.mainInterval>122&&(B.mainInterval=122))
case 122:
mainInterval:122

You can increase these values further based on how much activity you get. I unfortunately wasn't able to find a way to detect correctly if you're on a BuddyPress page, I found some documentation recommending using the bp_current_component() function, but it didn't seem to work in my testing as described.

Please let us know if you have any further questions.

- Jacob
n/a Points
2014-07-27 6:37 pm

Hi again and thank you a lot for your answer :)

The load more button only appears when there are 20+ comments (or activity messages) with the basic buddypress

 

Thank you for your advices, I will try it when I am back home and I will return to you if it is working better :)

Have a good day! :)Estellya

n/a Points
2014-08-09 10:51 am

Above code is not working for me.

i placed first code in my themes functions.php file and when i try to clear cache with w3 total cache it gives me blank page in output. sane when trying to post anything howeve post published but i see blank page instead of post page.

 

Regards

waseem

rspk.paksociety.com

Staff
18,017 Points
2014-08-11 12:03 pm
Hello Waseem,

What code did you place and where? Also, what steps and URL do we need to visit to cause the error? Be sure you have used the code in the article exactly as described to ensure there is nothing in there that broke.

Kindest Regards,
Scott M
n/a Points
2014-08-29 3:44 am

Hi Jacob,

I'm using WordPress 3.6 on Centos 6.4, my current theme : Twenty Eleven. I did "disabled wordpress heartbeat everywhere" by adding the highlighted codeinto /var/www/html/wordpress/wp-content/themes/twentyeleven/functions.php , clear cache in my browser but heartbeat didn't stop. I still see "POST /wp-admin/admin-ajax.php" from my ip in log.

Staff
18,017 Points
2014-08-29 10:54 am
Hello Jack,

After inserting in the functions.php, that should stop the heartbeat. Have you tested further with additional browsers?

Kindest Regards,
Scott M
n/a Points
2014-08-31 11:47 pm

Hi Scott,

I tested with IE, Firefox, Chrome, my browser still send request to server every 5 seconds. My client machine uses win7, where should I check if this "heartbeat javascript" is removed afterI clear cache ?

Staff
18,017 Points
2014-09-02 1:24 pm
Hello Jack,

Yes, please clear the caching and test again.

Kindest Regards,
Scott M
Staff
9,968 Points
2014-09-02 4:16 pm
Hello Jack,

Are you seeing the requests for /wp-admin/admin-ajax.php roughly every minute while you are just sitting in the WordPress dashboard? Or are you just seeing them fire once and then stop?

It's important to note that the Heartbeat API isn't the only thing that uses the admin-ajax.php script, and any plugin in WordPress that is trying to do some AJAX calls.

To confirm it's the Heartbeat API still calling the admin-ajax.php script you can open the Google Chrome Developer Tools by pressing F12 on your keyboard using the Google Chrome web-browser, then clicking on the Network tab.

Now go ahead and login to your WordPress dashboard, then wait a minute or so until you see a new admin-ajax.php request towards the very bottom of all of the requests. You can then click on admin-ajax.php to view what it's doing.

This is what a Heartbeat /wp-admin/admin-ajax.php POST would look like after clicking on it then looking under the Form Data section:

interval:60
_nonce:95ec4720f9
action:heartbeat
screen_id:dashboard
has_focus:false

If you don't see this, especially the part with the action:heartbeat, then this request isn't being caused by the Heartbeat API, but could instead be getting caused by a plugin you have installed.

- Jacob
n/a Points
2014-09-02 10:50 pm

Thank you very much Jacob,

You're right, I follow your suggestion and find out that Quick Count Keep Alive feature plugin did AJAX calls every 5 seconds, I turn it off.

n/a Points
2014-09-01 9:10 am

Hello Jacob,

Your post seems very helpful, but i am still facing an issue. Not sure what could be the reason, as doing pingdom tests "Admin-Ajax.php" is the file that is causing issues, even after completely disabling heartbleed API using your code mentioned above in theme's functions.php file.

Here is what i want to explain-

We have two different sites running same professional theme ("Blaszok" from Themeforest) on 2 different shared hosting accounts by Justhost (same plan)

Both sites have woocommerce running. Both sites have same recommended plugins only with same versions.

On this site - www.sigmabazaar.com i have not disabled Heartbeat API at all and it is running faster and showing good results in pingdom tests. Even though it has more than content than the other one on home page and overall.

Another site - www.ushaglobalphila.com in this site i have disabled Heartbeat API completely, and surprisingly this shows loads time from 30 seconds to 60 seconds, way too much. One can see that total number of requests and page size is also much smaller as compared to previous one and still it is taking too much time. Almost every time is being consumbed by "Admin-Ajax.php" file

I asked the hosting company, but they says, if this would have been the problem from their side, then it should also shows the similar problem in other site also. Apart from that they have checked their servers and settings too and did not find any such issue on their server.

Below are the test results for both the sites-

http://tools.pingdom.com/fpt/#!/jAYlF/http://www.sigmabazaar.com

(Much FASTER even with Heartbeat API enabled / no change, more content, more requests)

http://tools.pingdom.com/fpt/#!/dRM6zb/www.ushaglobalphila.com

(Much Slower, even with Heartbeat API disabled, lesser content everywhere, few requests)

Can you please look into the issue and guide me the proper way. May be either i am doing something wrong, or there is some another issue that is directly related to admin-ajax.php file, but might not be with Heartbeat API.

Please help me by suggesting.

Thanks and Regards

Staff
9,968 Points
2014-09-02 2:42 pm
Hello Anish,

Unfortunately a lot of people that seem to be reading this article are missing the fact that disabling the WordPress Heartbeat API is mainly for reducing the resource usage and to speed up the WordPress dashboard where the API is used. It's important to note that the admin-ajax.php script is not just used by the Heartbeat API, but anything in WordPress that wants to run some AJAX (Asynchronous JavaScript & XML) calls.

I haven't seen too many plugins that utilize the Heartbeat API on the front-end of the website, and it wouldn't make a whole lot of sense of the Heartbeats slowing down the site on the client side. The Heartbeat API simply causes your web-browser to POST a request back to the server's /wp-admin/admin-ajax.php script at a set interval to complete tasks such as auto saving and post locking in the admin dashboard.

I took a look at your second site in the Google Chrome Developer Tools by pressing F12 on my keyboard then loading your site. I do see that that /wp-admin/admin-ajax.php script is waiting the longest, and you can click on it to see what it's trying to do.

The particular call for /wp-admin/admin-ajax.php that you are seeing take a long time waiting is POSTing this data back to WordPress in the Form Data section of the Headers tab:

action: woocommerce_get_refreshed_fragments

This is what a Heartbeat /wp-admin/admin-ajax.php POST would look like:

interval:60
_nonce:95ec4720f9
action:heartbeat
screen_id:dashboard
has_focus:false

So this delay has something to do with your WooCommerce plugin. From taking a look around the plugin's code where woocommerce_get_refreshed_fragments is mentioned, this seems to be either dealing with creating secure https:// links, or checking if the browser supports local HTML5 storage. Then it seems to display HTML fragments that I assume would build up your cart, such as if an item has been added to it.

Another thing to note is that the /wp-admin/admin-ajax.php call should not be slowing down the loading of your website, as it is a request that should be processed after your site is done being loaded into the visitor's browser.

To best see this, I recommend testing your site locally in Google Chrome under an Incognito window (Ctrl-Shift-N) so nothing is cached to your computer. Once you have a new Incognito window opened, hit (F12) to open the Developer Tools, then click on the Network tab. Type in your website address and hit Enter and you should see your site start to load. Notice everything on the page is loaded, then the admin-ajax.php script at the bottom will say Pending... under the Status column for a few seconds while it waits for the WordPress WooCommerce function to run and then return via AJAX the response for that request, which you should then see the request change to 200 OK.

To confirm this is the issue, I'd recommend temporarily disabling WooCommerce, then run your speed test again. If you are running the same plugins on both of your WordPress sites, then it might have to do with the data stored in your database that is causing this script to take longer to load.

One thing that I notice on your site where it's taking longer to load is that when you hover over Buy in the menu, the first product category is Error. I'm not sure if that is the actual name you picked, or perhaps there is something going wrong at this level of the WooCommerce plugin that is in turn causing the admin-ajax.php call to take longer than on your other site.

I hope that information was helpful, please let us know if this resolve the issue for you.

- Jacob
n/a Points
2014-09-09 9:04 am

Hello Jacob,

First of all i would like to thank for such a thoughtful and clear explanation with in depth details. Even theme developers and hosting company didn't provide such information, even though they could.

From starting point, i didn't misunderstood about Heartbeat API at all, but just come across your beautiful post with such details, so thought to share it with you and ask for some better solution. As admin-ajax.php is the main culprit in pingdom tests and didn't show at all, while i disable woocommerce.

Here are more details as per your suggestion-

1. I first disable woocommerce, and found that it considerable improves the loading time sometimes 8-10 seconds, and somtimes even 3.5-5.5 seconds. Even though 8-10 seconds is not good, but it is then still much faster then previous timings. Here admin-ajax.php didn't loads at all. this shows in my specific site, it is being called by woocommerce only and with no other plugin.

2. In this step, i again enable woocommerce and then remove the menu named "ERROR" from the main menu bar, thinking that it might cause issues. But it didn't give me noticeable differences. The load times are still 17-21 seconds and very few times around 10 seconds. Admin-ajax.php consuming almost every time.

I could not delete the product category "ERROR" (shown as menu), as i did it intentionally. Here i mean by Error in philatelly items that were produced during printing in government press. This means a lot for all philatelists and is very much valuable for them.

Another reason is that, now few KWs have gained ranking in google in top 3, so it is hard for me to remove it for testings purposes only. KWs like "Gandhi error print", Gandhi print error, Gandhi error stamp, even the most competitive KW Gandhi Error brought it in 27-35 position. And there are few other KWs also which retains the rankings related to this "ERROR" word.

I am not sure, that if i change or delete this product category for about 15 minutes to half hour for testing purposes and then add it back, will it then retain the existing rankings or not, or it will affect them.

Also, i am testing this on latest versions of Chrome and Firefox and not using HTTPS at all. And the data stored in this site is very very small and is just for testing and initial purposes. I have only 3-5 products and very few pages, thats all. And the other site that i am comparing with has got lots of products and pages comparatively.

Now that i have concluded as per your helpful suggestions, i am still not clear about the main issue and root cause. I can't completely disable woocommerce either.

Can you please look into my site and this issue further. If you require, i can even provide you wordpress admin details for my site, if at all it is required.

Please suggest, i am really looking forward to resolve this issue.

Thanks and Regards

Staff
8,314 Points
2014-09-09 10:49 am
I've taken a look at your site and it appears that the main culprit for your page load times is Revolution Slider. Try disabling it and seeing how this impacts your server load. If it does, I recommend finding a new slider plugin for your site to replace it.

Also, be sure that if you are going to continue using Revolution Slider, that it is fully up to date as last week it was found to have a critical security vulnerability that can cause an entire site to become compromised.
n/a Points
2014-09-11 10:30 am

Hello Jeff,

I tried disabling Revolution slider and then checked again with pingdom, but nothing changed. It was showing the load times of 17-24 seconds. Sometimes above 32 seconds. So i didn't think to re-activate it and update it.

I then thought to switch my theme to another professional theme, which is "neighborhood" from Themeforest. But the moment i click on it to Activate it, the site goes down.

Now i am totally null, my site www.ushaglobalphila.com is not accessible. Neither the frontend nor the backend is showing anything.

I somehow managed to enable the debug mode and it is showing some sort of error with the switched theme. which was actually working fine before.

Can i request you to help me to get this site back UP and Live again. How can i switch or re-activate the previous theme "Blaszok" again from any area of cPanel or file manager. Because i can't access the wordpress dashboard at all.

Also, as i said Revolution slider don't seems to be culprit, atleast in our case. So can you suggest me what else can i do to rectify this issue and speed up the things.

Please help me and thanks for trying so much harder to help me out.

Thanks

Staff
8,314 Points
2014-09-11 10:44 am
Right now, the error that I am seeing is directly caused by the Visual Composer plugion. To disable it, simply remove your /wp-content/plugins/js_composer folder. You may use the cPanel File Manager to do so.

Post a Comment

Name:
Email Address:
Phone Number:
Comment:
Submit

Please note: Your name and comment will be displayed, but we will not show your email address.

Need more Help?

Search

Ask the Community!

Get help with your questions from our community of like-minded hosting users and InMotion Hosting Staff.

Current Customers

Chat: Click to Chat Now E-mail: support@InMotionHosting.com
Call: 888-321-HOST (4678) Ticket: Submit a Support Ticket

Not a Customer?

Get web hosting from a company that is here to help. Sign up today!