windmeile

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:

1. 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.
2. 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:

1. 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’
   ]);
2. 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

could you give me an update on this? where you able to reproduce it on your end?

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 there,

I did some further debugging and it seems it is indeed related to the plugin, rather than the theme or WP Bakery.

I checked the source code and this part of the code is causing the problem:

    // Localize/Inline Script
        static $ssqScCount=0;
        if (!$ssqScCount){ // First run we need to declare variable and input
            $inlineData = 'var ssqInput={};
            ssqInput='.json_encode($ssqInputZeroObject).';
            ssqInput.sc=[];
            ssqInput.sc['.$ssqScCount.']='.json_encode($ssqInputObject).';';
        } else { // All other runs just input 
            $inlineData = 'ssqInput.sc['.$ssqScCount.']='.json_encode($ssqInputObject).';';
        }

For some reason, when running the shortcode through WP Bakery it starts with $ssqScCount = 1. That is why it only prints the input and not the declarations.

When I remove “static” from the static $ssqScCount=0; declaration it will redeclare ssqScCount and force it to be zero with each run. This did the trick and the animations are now appearing, however, I then cannot have multiple shortcode on same page.

So instead I inserted a counter $run_check_mb = 1; into the if statement

// Localize/Inline Script
			static $ssqScCount=0;
			if (!$ssqScCount){ // First run we need to declare variable and input
				$run_check_mb = 1;
				$inlineData = 'var ssqInput={};
				ssqInput='.json_encode($ssqInputZeroObject).';
				ssqInput.sc=[];
				ssqInput.sc['.$ssqScCount.']='.json_encode($ssqInputObject).';';
			} else { // All other runs just input 

and then changed the near the end of the function the code into this:

if ( freemius_scrollsequence()->is_plan_or_trial__premium_only('PRO') ) { // Pro
			if ($run_check_mb == 1) { $ssqScCount++;} else { $ssqScCount = 0;}
			return $returnvar;
		} else { // Free

It works for me now. Can this fix be implemented in future versions, so I can still have the latest update? THanks for your support, the plugin is awesome!

wow, thanks alot for getting back so quickly. First, I updated the plugin to the latest version, then I deactivated cloudflare and some performance plugins but still same error.

You say “There is something that is removing the inline input script.”.

I can see that it is removing the first three lines of it…

var ssqInput={}; ssqInput={"debug":[],"show_footer":false,"show_sidebar":false,"preloadPercentage":"0.12","ssqFyiId":294373,"siteUrl":"https:\/\/windmeile.com"}; ssqInput.sc=[];

which is probably causing the console error.

After deactivating my theme (Uncode) it is working as expected, the error is gone, the inline input script is fully loaded and the sequence is showing up fine.

I guess I will need to talk to the devs of the theme unless you see another way on how to enqueue this inline script. Thanks anyways for your help and time.

Hi,

thanks for getting back. I double checked and we have the most recent version 3.8.3 and woocommerce 9.3.3. The error still appears.

Thanks for diving in.

how can this be explained then?