Performance issue on variable products
-
with the new version 10.2.0 we noticed massive increase in loading time > 5s of variable products (with many variations). query monitor shows many database requestes triggered by stripe.
when deactivating stripe plugin loading time goes back to 1-2 seconds.
Can you please solve that?
The page I need help with: [log in to see the link]
-
Hi there,
Thanks for sharing these details. I understand that you’re noticing a significant increase in page load times for variable products after updating to 10.2.0, and that Query Monitor shows many database requests triggered by the Stripe plugin.
To help us investigate this further, could you please:
- Share the Query Monitor report showing the queries being triggered by the Stripe plugin on the variable product pages. This will help us pinpoint what is causing the slowdown.
- Provide your System Status Report, which you can find under WooCommerce → Status. You can share the report using Pastebin or Gist and provide the link here.
Once we have both the Query Monitor data and the system status report, we’ll be in a much better position to identify the cause and suggest a solution.
Thank you!
Hi,
thanks for getting back. Here are the requested screenshots. First one with Stripe activated, second one with Stripe deactivated. Loading times are 5x higher with stripe.
Kind regards, Michael
Hi @windmeile, thanks for sharing the additional screenshots, they make the situation much clearer and are very helpful for moving this forward.
Looking closely at the screenshots, the difference is quite evident. With Stripe enabled, the variable product page shows a much higher total query count and execution time, and Query Monitor highlights repeated calls related to Stripe Express Checkout, including functions such as wc_stripe_express_checkout_helper_product_data, element javascript params, and element scripts. These appear alongside the WooCommerce data store calls for finding matching product variations, which explains why the impact becomes much more noticeable on variable products with many variations. When Stripe is disabled, those Stripe specific calls disappear and the overall load time drops significantly, matching what you described.
Based on this, the screenshots already confirm that the performance regression is tied to Stripe components loading on the product page rather than a general WooCommerce issue. The next useful step would be to capture the Query Monitor view filtered by Component and Caller, focusing specifically on the Stripe related entries, so we can quantify how often those functions are being triggered per page load. If you can share one more screenshot showing the Database Queries by Component panel with Stripe expanded, that would give us exactly what we need to raise this internally with very concrete evidence.
You can continue sharing screenshots via https://snipboard.io, and if you manage to export any text based Query Monitor output, share it using https://pastebin.com.
under components or caller I did not finy anything directly Stripe related, probably all under woocommerce. could you not just simulate it on your end? create a product with up to 200 variations, run query monitor on it. of course if you are not able to reproduce it, I am happy to help…
Hi @windmeile,
Thanks for that clarification, that makes sense.
We’ll go ahead and try to reproduce this internally on our side with a large variable product and Stripe enabled.
In parallel, could you also share a System Status Report from WooCommerce → Status?
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
This can help us confirm environment details (PHP version, HPOS state, caching, etc.) that may influence performance, especially when we escalate this.
This won’t block our testing, but it will help us make sure we’re comparing like-for-like.
sure here it is https://pastebin.com/VeZtRdZX
Hi @windmeile,
Thank you for getting back to us and for providing the system status report as requested. I understand that issues like this can be quite challenging. The extra step you took to observe the speed changes when enabling or disabling WooCommerce Stripe helps give us clearer direction.
To help further narrow down the root cause, we’d like to run an isolated conflict test. Although you’re noticing changes in speed when enabling or disabling the WooCommerce Stripe plugin, it’s possible the issue is being caused by another plugin or a conflict that involves WooCommerce Stripe.
At this stage we can’t be certain, but performing an isolated test will give us clearer direction. If this can’t be done on your live site, you can carry it out on a staging environment such as a subdomain, a separate directory, or a staging site provided by your hosting company. To start you’ll need to move a copy of your live site to the staging site.
On the staging site, please start by deactivating all plugins except WooCommerce and WooCommerce Stripe, then check the site speed. After that, deactivate WooCommerce Stripe and check the speed again. Kindly share updated screenshots similar to the ones you provided earlier.
It’s important that all other plugins remain disabled during this test so we can accurately determine whether the issue is a direct WooCommerce Stripe issue or a conflict involving another plugin.
We’ll be looking forward to your update.
could you give me an update on this? where you able to reproduce it on your end?
Hi @windmeile,
I want to clarify the intent of my colleague’s earlier message and keep this focused.
At this point, we have not been able to reproduce the performance slowdown on our end using large variable products with Stripe enabled. Because of that, the request to set up a staging site is to help isolate the behavior in a clean environment. Testing with only WooCommerce and WooCommerce Stripe active allows us to confirm whether this is a direct Stripe behavior or something influenced by the current site setup, theme, or other plugins.
Please set up a staging copy of the site, deactivate all plugins except WooCommerce and WooCommerce Stripe, then test the variable product performance again and share the results. This will give us the concrete data needed to move this forward confidently.
Thanks for working through this with us, we appreciate your cooperation and detailed testing.
come on guys, lets face it you didnt even try to reproduce is albeit I did all the hard work and provided everything needed to reproduce it and pinpoint the . that is disappointing. you are making money with this plugin not me. now its your turn! show me the query monitor output of your variable product with > 200 variations….show me that screenshot where you dont have these over 1000 unneccessary database calls involving WC_Stripe_Express_Checkout_*
Hi @windmeile,
Thanks for taking the time to dig into this and for sharing all the details. I understand why you’re frustrated, and I appreciate the effort you’ve already put into trying to pinpoint the issue.
To make sure we’re wasn’t missing anything, I went ahead and recreated a variable product with 300+ variations on my own test site.
I then opened Query Monitor on both the product page and the product edit screen. I wasn’t able to reproduce the database calls you’re referring to, specifically the
WC_Stripe_Express_Checkoutqueries. Those entries didn’t appear at all on my end. See screen recording: https://share.zight.com/NQuGBpW9.That suggests something else in your environment may be hooking into WooCommerce’s product/variation loading process and causing the extra queries to appear.
If it’s not too much trouble, could you set up a staging site and run the conflict test?
If you can share the Query Monitor output from that environment, it would help us narrow down what’s actually triggering those calls.Happy to continue investigating this with you once we have that info.
Hi Frank,
thanks alot for getting back and providing this useful information. The good news is, with the most recent plugin version the performance bottleneck is gone when deactivating express checkout on product page. As soon as this is activated the page loading time is 5 times higher. I am not sure why you dont have the heavy database call in your setup, maybe caching? maybe theme related, I dont know, however, we did some further debugging and we believe we found the root cause. Here is our analysis:
Two expensive operations run during wp_enqueue_scripts for every variable product page load:- get_available_variations() in should_show_express_checkout_button() class-wc-stripe-express-checkout-helper.php:740-741
if ( $is_product && $product && in_array( $product->get_type(), [ ProductType::VARIABLE, ‘variable-subscription’ ],
true ) ) {
$stock_availability = array_column( $product->get_available_variations(), ‘is_in_stock’ );
This loads all variation objects with full data (prices, attributes, images, stock, etc.) just to check if any are in stock. - find_matching_product_variation() in get_product_data() class-wc-stripe-express-checkout-helper.php:248-249
$data_store = WC_Data_Store::load( ‘product’ );
$variation_id = $data_store->find_matching_product_variation( $product, $attributes );
Queries database to find matching variation on initial page load.
Suggested Fix:
- Replace get_available_variations() with a lightweight stock query:
// Instead of loading all variation objects, query stock status directly
$in_stock_count = wc_get_products([
‘parent’ => $product->get_id(),
‘stock_status’ => ‘instock’,
‘limit’ => 1,
‘return’ => ‘ids’
]); - Defer find_matching_product_variation() to JavaScript/AJAX rather than running on initial page load, or skip when
no attributes are pre-selected.
Hope this helps!
Michael
Hi Michael,
Thank you for the detailed follow-up and for taking the time to dig this deep. This is extremely helpful, and I appreciate you sharing both the findings and the suggested fixes.
Your analysis makes sense and clearly explains why the performance impact is so severe on large variable products. Calling
get_available_variations()andfind_matching_product_variation()duringwp_enqueue_scriptsmeans all variation data is being loaded on every page view, which scales very poorly as the number of variations grows. That aligns well with the Query Monitor results you observed and explains why disabling Express Checkout immediately improves load times.The fact that disabling Express Checkout on the product page resolves the bottleneck confirms that this behavior is isolated to the Stripe Express Checkout logic rather than WooCommerce core itself.
Differences in environment, caching, or theme behavior may explain why we didn’t observe the same query volume in our test setup; however, your findings clearly indicate a real-world performance issue.
Your proposed improvements, using a lightweight stock query instead of loading all variations, and deferring
find_matching_product_variation()until it’s actually needed, are very reasonable and align with WooCommerce performance best practices.I will pass your analysis and suggestions directly to the Stripe development team, so they can review this logic and evaluate potential improvements for a future release. In the meantime, disabling Express
Checkout on variable product pages with many variations is a sensible workaround.
Thanks again for the thorough investigation and for sharing actionable insights. This kind of feedback is genuinely valuable, and we appreciate you sticking with us on this.
Hi @windmeile just checking if you received our last message ?
we did. is there any doing on our side?
You must be logged in to reply to this topic.
