Hi @theunnicked,
I understand the concern around the admin slowdown you are seeing after enabling the plugin, and I want to make sure we fully understand the conditions that led you to applying the workaround so we can narrow this down accurately.
Before adding the script to remove all callbacks on the google_for_woocommerce_admin_menu_notification_count filter, could you share what other troubleshooting steps you tried first? For example, did you test with other plugins temporarily disabled, switch to a default theme, or check for any errors or notices showing in the admin area?
It would also help to clarify what you are seeing in terms of performance. When you mention poor backend performance, what kind of loading times were you experiencing on the affected admin pages? I have tested this on my side with Google for WooCommerce enabled, and I am not able to reproduce the same behavior. On my test site, the initial admin page load is within about 10 seconds, with the complete load finishing within roughly 20 seconds.
Given that difference, there is a chance another plugin or custom setup on the site is interacting with or amplifying the behavior of that filter. Any additional details you can share about the environment or steps you took before applying the workaround will help us determine whether this is a broader issue or something specific to a particular setup.
I’ve observed this behaviour on a clean WordPress install with a default theme.
Here are the reproduction steps:
- Install Worpress (v6.9.1) with theme Twenty Twenty-Five (v1.4)
- Install and activate WooCommerce (v10.4.3), Google for WooCommerce (v3.5.2) and Black Bar (v4.1.4)
- Complete the setup of Google for WooCommerce plugin connecting the store to the Google Merchant Center
Black Bar is a profiling plugin that is used to measure performance of specific hooks.
google_for_woocommerce_admin_menu_notification_count hook starts to have a significant impact on load time AFTER completing the setup of Google for WooCommerce.
Before connecting the store to wordpress.com and to Google Merchant Center, the execution of the hook took around 20ms, after connecting the execution time increased to over 1.5s. Overall load time after completing the plugin setup changes from 500ms to 4.5s. The performance impact is observable only in the admin panel. I did not observe any performance change on the front end.
Hi there!
Thank you for providing the detailed reproduction steps and performance observations — that is very helpful.
To allow us to forward this issue to our developers for internal investigation, we’ll need a copy of your System Status Report which you can find via WooCommerce > Status
Please use https://pastebin.com/ or https://gist.github.com/ and share a link to that paste in reply here. Once we have more information, we’ll be able to assist you further.
Hi @theunnicked,
Thank you for sharing your System Status Report and detailed observations. I noticed that your environment is running a clean setup with WordPress 6.9.1, WooCommerce 10.4.3, Google for WooCommerce 3.5.2, and the Twenty Twenty-Five theme. I also observed that the Daily Cron is not scheduled, and I wanted to check whether this was turned off intentionally.
Regarding your earlier note that the overall admin load time increases from 500ms to 4.5s after completing the plugin setup, this performance change is expected. Once the plugin interacts with WordPress.com and Google Merchant Center, additional processing occurs, which naturally impacts admin page load time. Given this, the observed timing is not considered abnormal.
Everything else in the status report looks standard, with no errors or unusual configurations observed that would further impact performance. This means the admin experience is operating within normal expectations given the plugin’s interactions.
Let me reiterate. The issue that I’m reporting is: your functionality of getting a notification count for a badge in the admin menu impacts the admin panel load times on all of the admin pages. The performance issue seems to be localised only to a filter google_for_woocommerce_admin_menu_notification_count , because once it is disabled, the performance returns back to normal levels, with Google for WooCommerce turned on and configured.
I’ve managed to reproduce this issue on a clean WordPress install.
I can disable the filter using
add_action( 'admin_menu', function () {
remove_all_filters( 'google_for_woocommerce_admin_menu_notification_count' );
}, 0 );
and the performance returns back to expected levels.
I suggest that one of your devs looks at the performance impact of getting the notification count and maybe consider caching the response, because such an expensive function shouldn’t be called on each page render.
+1
I am also facing this issue with one of my ecommerce store using the Google for WooCommerce plugin. The code snippet provided by @theunnicked fixes the poor admin loading speed issue. This issue started to happen recently. Disabling the plugin also fixes the issue. But for now, I’ve used the code snippet to temporarily fix the issue.
Hi @theunnicked and @nitishk
Thanks for sharing more details about the issue. I’ll share this with our developers and follow up once I hear back from them.
Hi there!
Thank you for sharing the workaround. Our developers are currently working on the performance issue, and we’re hopeful it will be addressed in an upcoming update.
You can keep an eye on this GitHub thread for progress and updates on the issue:
https://github.com/woocommerce/google-listings-and-ads/issues/3184
I’m going to mark this as resolved, as we haven’t heard back from you in a while. Please open a new thread if you need further assistance.
We’d love your feedback – please leave us a review: https://wordpress.org/support/plugin/google-listings-and-ads/reviews/
@kingsleyinfo It’s still an ongoing issue. The github thread has not been resolved and no update fixing this problem has been released.
I’m still waiting for a proper fix, not a workaround.
Hi there!
Thank you for the update.
I understand your concern, and we appreciate your patience while this is being worked on. Our developers are actively investigating and working toward a proper resolution for this issue. However, at the moment, we don’t have an ETA to share regarding when an official fix will be released.
Please rest assured that progress is ongoing, and updates will be posted on the GitHub thread as soon as more information becomes available. We recommend keeping an eye on that thread for the latest developments.
Since there’s been no recent activity on this thread, I’m marking it as resolved. Don’t hesitate to start a new thread if you need help in the future.
