Slow queries with wcpay incentives?
-
Hey there,
Could we stop querying wcpay incentives per pageload in the admin? It seems that currently with each admin page in any page the incentives promotion stuff is loading. In our case the wcpay doesn’t cover 90% of the most used payments options so this kind of promotion is useless for us currently.
-
Hi @nikov, I understand how constant incentive queries loading on every admin page can feel unnecessary in your case, especially when WooPayments does not currently support most of the payment methods you rely on. I appreciate you highlighting the performance angle here, and I will help point you in the right direction.
The incentives checks are part of WooPayments’ built-in promotional logic and they currently run in the background to determine eligibility. There is no setting available in WooCommerce or WooPayments to disable those checks at the moment. Your feedback is very valuable though, and sharing it helps the team better understand real-world impact on stores.
If you would like to request a change or add weight to an existing discussion, you can share this directly with the developers through the public WooIdeas board where feature requests are tracked
https://woocommerce.com/feature-requests/. You can also learn more about WooPayments features and configuration here https://woocommerce.com/document/woopayments/If you can share a system status report via https://pastebin.com or https://quickforget.com I can also take a closer look at the overall load time to ensure nothing else is contributing to the slow queries. Let me know once you have the report and I will be here to help further.
Hi, thank you for the reply!
I understand that WooPayments currently has no setting to disable the incentives logic, but I want to clarify that the issue here is not about configuration preference — it’s about developer best practices.
WooPayments is performing external HTTP requests on every wp-admin page load, even when the user is not on a WooPayments screen.
According to both the WordPress Plugin Developer Handbook and the WooCommerce Extension Development Guidelines, this pattern is considered a bad practice:
- “Avoid remote HTTP requests in wp-admin unless strictly required for the current screen.”
- “Extensions should only load code and run remote calls on the screens where the feature is actually needed.”
- “Do not add global admin overhead.”
The current incentives request violates these principles by:
- Running globally on every admin request
- Being unrelated to most screens it loads on
- Adding an external dependency to routine admin navigation
- Creating unnecessary latency for stores that do not use WooPayments
This isn’t a feature preference — it’s a matter of following established WordPress/WooCommerce extension architecture standards.
I’m happy to file a feature request on WooIdeas, but since this concerns best practice compliance, could you please forward this directly to the WooPayments engineering team as a technical issue?
Even simply caching the incentives result once per day, or scoping the query to WooPayments-related screens, would align the extension with the documented guidelines and avoid unnecessary admin overhead.
Thanks again for helping escalate this properly!
Thanks for the detailed explanation, which really helps clarify the concern.
You’re right that the guidelines recommend avoiding global remote requests in wp-admin unless they’re needed for the current screen, and I understand why these WooPayments incentive checks feel unnecessary in your setup. I’d like to gather a bit more information so I can pass this along to the team for review.
Could you please share your System Status Report?
You can get a System Status Report by going to WooCommerce > Status > Get system report, then paste it into https://pastebin.com or https://gist.github.com
Once I have that, I’ll forward this internally so the team can evaluate whether the current behavior aligns with best-practice expectations or if adjustments are appropriate.
Thanks again for bringing this up. Your technical feedback is genuinely helpful.
Hey Niko,
I’m happy to file a feature request on WooIdeas, but since this concerns best practice compliance, could you please forward this directly to the WooPayments engineering team as a technical issue?
Just following to up let you know that my engineering teams have received this and are looking into it.
Hi @nikov, I am a Software Engineer working on the WooCommerce and WooPayments codebases.
Thanks for raising this issue, and I agree that we should not send external HTTP requests for every page load, especially for non-critical info like incentives. Let me go into the technical details a bit deeper.
Current caching strategy
The
GET https://public-api.wordpress.com/wpcom/v2/wcpay/incentivesrequest is initiated in this get_incentives method. Before and after calling this HTTP request, the code has tried to do two types of caching:- in-memory: to ensure that for every HTTP request to your WordPress site, there is a maximum of one GET request above).
- transient: can be either object cache such as Memcached/Redis/etc, or simply wp_options if sites do not have object cache. This ensures that the response for the GET request above will be cached for 6 hours if it’s an error, and 24-48 hours if it’s successful (status 200).
Possible causes
I have tried to replicate this issue on my testing sites, both local and a hosting site. However, I do not get the issue you mentioned here. Furthermore, looking at the Git blame, the relevant code has been in the codebase for nearly one year. Given all of these points, it’s likely that your site or hosting has some specific settings or cache that the relevant codebase is not covering well.
Next steps
We’re keen on figuring out what the cause is and iterating on the current codebase. To figure out the cause, it would be helpful for us if you could:
- Provide us the System Status Report (as mentioned above)
- Try to disable other plugins and keep only WooCommerce, and see if the issue exists
- Based on your screenshot, it seems you’re using the Query Monitor plugin, could you provide screenshots for the
Transient Updatessection too.
Hey everyone,
Thanks for looking into this issue. It actually was a case of redis stuck in a endless loop. It was not just wcpay that was always updating. It was a lot of the other plugins too. Clearing and disabling the redis completely cleared the slow downs on the admin.
Hi @nikov, thanks for sharing this update with us, and it is great to hear that you were able to track the behaviour down to Redis being stuck in an endless loop. That kind of insight is genuinely helpful and gives more clarity on why those repeated updates appeared across multiple plugins, not just WooPayments.
Since things are running smoothly again after clearing and disabling Redis, you can continue to monitor the site over the next couple of days to make sure the performance remains stable. If anything similar crops up again or you notice patterns that might help us understand the environment better, feel free to share those details here. We are always around to look deeper whenever you need.
It’s been a while since we heard back from you for this reason we are closing this thread.
If WooCommerce has been useful for your store and you appreciate the support you’ve received, we’d truly appreciate it if you could leave us a quick review here:
You must be logged in to reply to this topic.
