codeloghin

Hello,

Thank you for your question.

An efficient heartbeat frequency can help mitigate issues such as increased server load, which may cause the backend to run slowly. That said, there can be multiple reasons for backend performance issues, including hosting plan limitations, database clutter, conflicting plugins, and more.

Dynamic Front-end Heartbeat Control includes an additional utility that allows you to clean unnecessary clutter from your database and optimize it. You may try installing and activating the plugin, clearing your cache, and then allowing it to run for a few minutes before checking whether there is any improvement in backend performance.

If the issue persists, you can navigate to WP Admin Dashboard > Settings > DFEHC > Database Optimization, enable the Manual Database Optimization option, and click Save Changes. This will add a new admin menu page called “Unclogger.” From there, you can review whether you have an excessive number of revisions, trashed posts, or transients that may be slowing down your database and backend. If so, cleaning them up should help restore normal performance.

If the problem continues beyond this point, it’s usually best to consult your developer or hosting provider, as the issue may require a more in-depth investigation.

Best regards,

Hello,

Thank you for reaching out. A new version of the plugin will be released at the beginning of next week, featuring improved compatibility across various hosting environments along with enhancements for multisite support. This update should address the CLI issues you’re currently experiencing. If not, I’ll be happy to troubleshoot further and ensure everything gets resolved.

Please don’t hesitate to reach out if you have any other questions in the meantime.

Kind regards,

Hi there,

Thank you for reaching out. I appreciate your feedback.

The plugin probes your own site’s REST endpoint to work out a baseline response time:

1. It builds https://example.com/wp-json/?_dfehc_ts=....
2. It tries wp_remote_head() first (quick, no body).
3. If that fails it falls back to wp_remote_get().

Because your staging site is protected by HTTP Basic Auth, WordPress’s HTTP API sends the probe without any Authorization: header, so Apache/Nginx responds with 401.
From WordPress’s point of view this looks like a broken request, but the plugin simply notes the failure and falls back to the default response time. Nothing on the front end breaks, you just get extra noise in Query Monitor.

To mitigate this on your staging setup, you can integrate the following filters either at the end of the heartbeat-controller.php file in the main plugin directory or your main functions.php file:

add_filter( ‘dfehc_request_pause_us’, 0 );
add_filter( ‘dfehc_num_requests’, 1 );

If you have any other questions or if you still experience any issues, feel free to reach out.

Best regards,

Hello,

Thank you for your question. Your issue seems to come from your web server configuration paths not being properly set up. Kindly check the plugin’s root directory, folder ‘defibrillator’ to confirm that the file ‘cli-helper.php’ exists and has the proper access permissions set by your web server. I recommend you look into the relative and absolute paths, in the file system and on the web server as it sounds like your issue comes from a misconfiguration there. This can impact functionality beyond just this plugin.

For any other questions feel free to reach out!

Kind regards,

Codeloghin