/?wc-ajax=get_refreshed_fragments

There is nothing intensive or complex about this endpoint: https://github.com/woothemes/woocommerce/blob/f95ffe16d034a8019f8fe0355d41998b84560182/includes/class-wc-ajax.php#L165

The only difference would be that as this is an ajax POST, it bypasses cache.

Sorry Mike, unfortunately Im not that “endpoint” savy . . .

All I know is I switch of WooCommerce and the exceptionally long wait times for this ajax refresh fragments disappear tested via tools.pingdom.net . . . . . I switch it on and 6 – 8 seconds of extra waiting on the site . . .

coupled with a base theme of 3 seconds . . .

I just need to find a work around as I advise my current employer to go with WordPress and WooCommerce as an eCommerce solution as that is what I was familiar with . . .

If you could help I would sleep better . . .

All I know is I switch of WooCommerce and the exceptionally long wait times for this ajax refresh fragments disappear tested via tools.pingdom.net . . . . . I switch it on and 6 – 8 seconds of extra waiting on the site . . .

Well that should be expected because this endpoint is only used by WooCommerce. What I was saying earlier was, this endpoint has no resource intensive code inside, so I doubt its the actual issue here and is more likely just a combination of plugins relying on WooCommerce, and the extra overhead of these plugins.

Ping something random to see if its still as slow:

/?wc-ajax=testing

There seems to be an issue here

https://support.woothemes.com/hc/en-us/community/posts/201220087-Woocommerce-Causes-Slow-admin-ajax-php-Load-Times?page=2#comments

with 36 people following a 2 page thread

Well no, admin-ajax.php is not even used anymore. See my previous reply.

This guy posted a year ago

With what can only be described as the most involved fix I can think of

Is anything he is saying of relevance if I attempt his fixes will this possibly remedy my problems ?

Doesnt seem like an isolated incident this issue ? and it seems to effect a number of people . . .

My earlier post seems to be stuck in pending review and I feel this info is important to share and get some feedback on, so I’m reposting it here, if this does not get published I will raise a separate ticket but it belongs here,

Hi,

here’s my latest info. I increased memory to 1Gb as advised by Martin, and set my memory limit and max memory limit to 1024M in wp-config.php and ran the pingdom test with woocommerce on, and still got admin-ajax.php wait time added making it very slow.

Now switching woocommerce off last does remove this, but other plugins also use it and the root cause seemed to be attributed to the heartbeat api built in to WordPress, There are ways to switch that off – which does cause issues with post updates, and also ways to switch it down – i.e. only use on posts, as per the following references, plus slow it down form every 15s to 60s.

Woocommerce issue seems to be related to calling the scripts on every page, and that is something definitely for the Woo guys to address, in the meantime there is a way to set this up only to call the scripts on shop pages as per following reference.

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

and the switching heartbeat down can be done in your theme functions file reference this..

https://www.outscream.com/heartbeat-api-the-heart-of-wordpress/

(note code shown has html in it which needs removed but see my working code below.)

and a good explainer here.. https://www.markomedia.com.au/admin-ajax-php-high-cpu-problem-solved/

There is also a plugin, ref here, which you can use to switch it down to only posts and also to increase the time between calls – I haven’t tried that yet but may be good for folks who don’t want to mess with functions.php (which you should do in a child theme so it doesn’t get overwritten on theme updates)

https://www.inmotionhosting.com/support/website/wordpress/heartbeat-ajax-php-usage

ok, so here’s what I added to my child theme’s functions.php – first the code to disable heartbeat except for Autosave..

addaction( ‘init’, ‘stopheartbeat’, 1 );
function stopheartbeat() {
global $pagenow;
if ( $pagenow != ‘post.php’ && $pagenow != ‘post-new.php’ )
wpderegister_script(‘heartbeat’);
}

That also seems to speed up the back-end admin as well, but main purpose seems to be reducing server cpu load and keeping your admin dashboard open seems to cause issues at certain hosts, so this code is useful for that (my admin is always open ??

and the code to slow it down to 60s;

function wptuts_heartbeat_settings( $settings ) {
$settings[‘interval’] = 60; //Anything between 15-60
return $settings; }
add_filter( ‘heartbeat_settings’, ‘wptuts_heartbeat_settings’ );

and now the code to stop woocommerce scripts loading on every page..

I’d really like the Woo Guys to check this out and comment, plus institute a fix if this issue is recognised as contributing – and I can assure you it does.. how about letting us do this per page – i.e. switch the woocommerce script load on or off..dependent on whether the individual page will have woocommerce on it

/**
* Optimize WooCommerce Scripts
* Remove WooCommerce Generator tag, styles, and scripts from non WooCommerce pages.
*/
addaction( ‘wpenqueuescripts’, ‘childmanagewoocommercestyles’, 99 );

function childmanagewoocommercestyles() {
//remove generator meta tag
removeaction(‘wphead’, ‘wcgenerator_tag’);

//first check that woo exists to prevent fatal errors
if ( function_exists( ‘is_woocommerce’ ) ) {
//dequeue scripts and styles
if ( ! is_woocommerce() && ! is_cart() && ! is_checkout() ) {
wp_dequeue_style( ‘woocommerce-layout’ );
wpdequeuestyle( ‘woocommerce-smallscreen’ );
wpdequeuestyle( ‘woocommerce-general’ );
wpdequeuescript( ‘wc-add-to-cart’ );
wpdequeuescript( ‘wc-cart-fragments’ );
wpdequeuescript( ‘woocommerce’ );
wpdequeuescript( ‘jquery-blockui’ );
wpdequeuescript( ‘jquery-placeholder’ );
}
}

}

I don’t know how that is going to affect overall performance of Woocommerce but it solves the admin-ajax load with issue on my site home page.

I have to say that as a great fan of WP and Woocommerce my enthusiasm has been dented and so has my confidence in this as a solution. Technically and on the back-end it is superb, but if it doesn’t work for customers and they bug out due to load times, and this also affects SEO performance, then what is the point…

So, I hope that helps others, and I would love to hear from the Woo team re the above code and the implications for woocommerce.

Incidentally, with the above code in place I lowered my memory limit down to 16M and the admin-ajax is still out, so it doesn’t appear to be a memory allocation issue, at least on my server.

I also tried these separately, i.e. heartbeat vs woocommerce code to see which removed the admin-ajax.php wait time.

The hearbeat code does not affect it, although I understand it will still help with cpu load on the server, but the code that takes out the admin-ajax.php wait is the Woocommerce code, so it is in fact Woocommerce loading its scripts to every page that is the real issue here..

Comments Woo guys…?

and surely you can replicate this..

Is my code correct, will it make my site shop work ok, and will you address the issue of your scripts adding this overhead to every page..

thanks..

imacg

Digging up old threads is not going to help – we used to use the generic WordPress ajax endpoint, admin-ajax.php, but have switched long since then to avoid the issues above.

I suggest you look at the plugins you have installed along WC, and see how they affect the wait time when pinging the site.

And rather than relying on an external ping tool, use the network tab in your browser developer console.

ok will do thx for the pointers

Tested the site switched off all plugins . . just left on WooCommerce on . . .

I realize you said test via the browser inspector and I did . . . couldnt see any reference in the chrome network tab inspector with reference to :

/?wc-ajax=get_refreshed_fragments

But testing it again in tools.pingdom.net its showing 4.09s just on

https://made-in-wood.co.uk/?wc-ajax=get_refreshed_fragments

Every other plugin switched off

https://tools.pingdom.com/fpt/#!/bobCx0/https://made-in-wood.co.uk/

You need something in your cart or the script is never called.

Once you do, look here: https://dl.dropboxusercontent.com/s/4i8xb14rbgk5hvv/2016-02-15%20at%2013.27.png?dl=0

hey @mike iam having the same issue this endpoint is causing my site to load like 8sec…
I thought some plugins are causing the issue but when i disable everything except the woocomemrce the problem remains if i disable woocommerce problems solved…
check here
https://tools.pingdom.com/fpt/#!/egjRcs/https://www.tastery.com.au
I have also bypas the link in my cache plugin https://www.tastery.com.au/?wc-ajax=get_refreshed_fragments

but nothing helps

As I said above, use the network tool, not pingdom, to see how fast it loads.

I’m also facing same issue. wc-ajax is causing long load times.
Load times from network tool (frontapge of the site)

hene, have you ruled out WPML? That would add load – look at the url. It contains /en/.

Again, there is nothing special about this endpoint. All it does is output the mini-cart. It’s uncached for that reason.

As the original thread starter .. . I can say that I no longer have a speed issue . . moved from EukHost to Siteground . . . speed issues resolved . . . it isnt necessarily always the scripts your running .. . started a wordpress and woocommerce install from scratch after speed issues on half built website with EukHost and I still had same speed issues . . . so moved the half built website and the scratch built sites to siteground . . . speed issues disappeared . . . so it turned out for me . .

/?wc-ajax=get_refreshed_fragments

wasnt the issue . . in the end . . .

Eukhost was