New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A way to prevent unnecessary AJAX? #9365
Comments
De-enqueue the script. WC has no way to know if your page does or does not have a cart widget on it. |
For anyone who finds this, here's an example:
Though, personally In think WC could be improved by defining a constant if any of the in-built cart widgets are painted... and then a developer could use that constant to de-queue if he finds that constant not set. (Of course, this won't catch the case of third-party widgets/page elements that rely on it - but they could also start using the constant. And every little helps). |
Hey #DavidAnderson684, Happy New year! Newbie question: Where do I place "add_action( 'wp_enqueue_scripts', 'dequeue_woocommerce_cart_fragments', 11); function dequeue_woocommerce_cart_fragments() { if (is_front_page()) wp_dequeue_script('wc-cart-fragments'); }" |
Hi @vanhallman you need to add in your functions.php theme. I have tested it and it founds! ;) |
Thank you. but where exactly i need to put this code ? at last line before } ? |
That example works great. |
The placed code is working fine for homepage, but I still can find "?wc-ajax=get_refreshed_fragments" on Posts and some other pages. Did you check them too or there is no problem on your site(s) ? |
Try this - I just put it in place and we're humming along fine with 139k uniques a day. add_action( 'wp_enqueue_scripts', 'dequeue_woocommerce_cart_fragments', 11); Note: pretty sure this willmuck with things if you have cart notifications and such in your theme, or if you try to embed products or other WC widgets on post pages. But if you know you don't have cart elements on post pages, it'll work. |
If anyone is interested, we made a free WordPress plugin based on this GitHub issue: https://wordpress.org/plugins/disable-cart-fragments-littlebizzy/ |
We're hitting this issue too with added load times between 1 and 2 seconds. Dequeuing fixes the issue, but what effect will this have on my store? Is this script needed for core functionality? What are the caveats of it not being enqueued? Can something break? |
Do you have mini cart in the header of that store, if not then you will be fine. |
@lukecav Do you mean the little cart icon that can be added to the navigation? We do have that as a part of our menu. It will show a numeric value depending on the number of items in the cart. If that's what you mean, we're happy to get rid of that to save 1 to 2 seconds of load time. |
Yep correct cart icon in the header, replace it for a menu link in the nav to the cart page on the site. |
hello, as I do not have any ajax cart on my shop, can I disable cart fragment for whole website with this code ? Thank you for your help. |
Nope, there is no built-in functionality to disable cart fragments, you must use the plugin. If the plugin is active, no defined constant or otherwise is needed. |
hello, I finally found this, so it seems that the plugin is not needed ? Thank you. /**
|
This is not a good solution... |
Did you ever get to fix this? |
This seems to work: I simply replaced the woocommerce button in my header with a button which is linking straight to my cart page. No ajax needed anymore. The user has to change pages to see the cart, but it saves ~1s on each page. |
hello, is it better than my code above ? thanks. |
To be honest, I did not try your code @makeonlineshop, since @pieterjanliekens said it might not be good. I am not entirely sure why though. However, nuking a function and simply disabling it probably makes a difference. |
It's always been available on GitHub: |
That is great @jessuppi, I might try this instead. I just saw that it is unavailable for download on wordpress.org since last month. Thank you very much. |
wc-cart-fragments are the items in the cart, For now I've deenqued it on the homepage, so initial page loads take 2-3 seconds less long. |
Dequeuing will work however you have to do it after anything else might have enqueued it. This will fix it. https://www.eckmandesign.com/blog/is-woocommerce-slowing-down-your-site-lets-fix-it/ |
added that snippet however /wp-content/plugins/woocommerce/assets/js/frontend/cart-fragments.min.js?ver=3.8.1 is still loading on GTMETRIX waterfall... Is it because it is the shop page? and is_archive() should be added too? |
we can remove that completely but it will not show mini cart items when page load or refresh, so any one how to call this function after window load, so it will not effect for speed scores on major sites like gemetrix |
Hello guys. somebody can help me out? ?wc-ajax=get_refreshed_fragments | (canceled) I got this call from all the pages even if that i don t have a cart in the site, and it let me lose 5 sec. What can I do? |
You can disable that cart fragment request using this plugin. |
What about if I would like to do it manually instead installing others
plugin?
…On Tue, 6 Apr 2021 at 22:54, Luke Cavanagh ***@***.***> wrote:
@fradaspa <https://github.com/fradaspa>
You can disable that cart fragment request using this plugin.
https://wordpress.org/plugins/disable-cart-fragments/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9365 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AS6I3W37JZL7A763T2H63ULTHNYKBANCNFSM4BR5GQHA>
.
|
I'm currently looking at the performance of multiple WooCommerce-powered websites' home pages.
On each of them, the home page is (or could be) entirely being served from CDNs and caches, except for one PHP call invocation, for WC's ajax call (?wc-ajax=get_refreshed_fragments).
Since the home pages have nothing WooCommerce-related on them - no cart, no products, nothing - this seems like it something that could be optimised away.
I can't see any way to accomplish this. As far as I can see, WC neither attempts to optimise this call away itself, nor provides a way for a site builder to manually force it. As a result, every page on the site, regardless of whether the page has any WC-related content, generates a call to PHP on the back-end. This looks like it may be the largest contributor to server load for many pages, given that, as I say, they're otherwise being delivered from cache/CDN.
Is there any way in which this aspect of site performance can be improved, even if it has to come down to "a site builder has a way to manually force some pages to skip this call" ?
The text was updated successfully, but these errors were encountered: