Just adding that I am able to replicate this behaviour on a site with just StoreFront (3.9.1), WooCommerce (5.7.1) and WooCommerce Stripe Gateway (5.6.2). I also have the Payment Request Buttons and New checkout experience disabled. Not sure if this is the intended behaviour.

Hi there,

I have the same issue on my site, just a quick look into the code shows the issue very clearly:

File: /includes/class-wc-gateway-stripe.php Lines 405 to 416

public function payment_scripts() {
		if (
			! is_product()
			&& ! WC_Stripe_Helper::has_cart_or_checkout_on_current_page()
			&& ! isset( $_GET['pay_for_order'] ) // wpcs: csrf ok.
			&& ! is_add_payment_method_page()
			&& ! isset( $_GET['change_payment_method'] ) // wpcs: csrf ok.
			&& ! ( ! empty( get_query_var( 'view-subscription' ) ) && is_callable( 'WCS_Early_Renewal_Manager::is_early_renewal_via_modal_enabled' ) && WCS_Early_Renewal_Manager::is_early_renewal_via_modal_enabled() )
			|| ( is_order_received_page() )
		) {
			return;
		}

! is_product() basically means whatever option is set is not taken into account just continue to enqueue the scripts on the product pages.

From my understanding it should be something like this:

public function payment_scripts() {
		if (
			( ! is_product() || ( is_product() && $this->payment_request !== 'yes' ) )
			&& ! WC_Stripe_Helper::has_cart_or_checkout_on_current_page()
			&& ! isset( $_GET['pay_for_order'] ) // wpcs: csrf ok.
			&& ! is_add_payment_method_page()
			&& ! isset( $_GET['change_payment_method'] ) // wpcs: csrf ok.
			&& ! ( ! empty( get_query_var( 'view-subscription' ) ) && is_callable( 'WCS_Early_Renewal_Manager::is_early_renewal_via_modal_enabled' ) && WCS_Early_Renewal_Manager::is_early_renewal_via_modal_enabled() )
			|| ( is_order_received_page() )
		) {
			return;
		}

Would be really nice to have a fix merged for this!

That's a good idea. Thank you, @PaulSchiretz .

In addition, you could also include a filter, so that theme/plugin developers can add or remove conditions. So basically this:

if ( apply_filter 'wc_stripe_exclude_payment_scripts',
	( ! is_product() || ( is_product() && $this->payment_request !== 'yes' ) )
	&& ! WC_Stripe_Helper::has_cart_or_checkout_on_current_page()
	&& ! isset( $_GET['pay_for_order'] ) // wpcs: csrf ok.
	&& ! is_add_payment_method_page()
	&& ! isset( $_GET['change_payment_method'] ) // wpcs: csrf ok.
	&& ! ( ! empty( get_query_var( 'view-subscription' ) ) && is_callable( 'WCS_Early_Renewal_Manager::is_early_renewal_via_modal_enabled' ) && WCS_Early_Renewal_Manager::is_early_renewal_via_modal_enabled() )
	|| ( is_order_received_page() )
	) ) {
	return;
}

Plugin team, please action this soon.

Can please someone have a look at this! I mean this issue might be solved in 10minutes and it would help so many of us, just give us something a filter or anything....
This issue is mentioned so often and i really wish this can be looked at, we don't need a new version with UPE or anthing by tomorrow but a working plugin would be nice!

References of the same issue over and over again:
https://wordpress.org/support/topic/v5-6-0-scripts-block-the-loading-of-product-pages-for-about-1-second/
https://wordpress.org/support/topic/stripe-js-loading-on-product-page-destroys-site-speed/
https://wordpress.org/support/topic/stripe-plugin-slowing-down-site/
https://wordpress.org/support/topic/stripe-js-loaded-on-product-pages-although-payment-request-buttons-are-disabled/
https://wordpress.org/support/topic/product-page-size-increases-by-50-with-version-5-5-0/
https://wordpress.org/support/topic/stripe-loads-on-product-page-3/
https://wordpress.org/support/topic/im-sorry-but-5-7-0-is-a-big-mess/

I too found my way here with poor page time load performance on product pages linked to stripe.js loading times...

Current Proposal Undesired? - review Stripe documentation

... however on reading the Stripe documentation

Include the Stripe.js script on each page of your site—it should always be loaded directly from https://js.stripe.com, rather than included in a bundle or hosted yourself.

To best leverage Stripe’s advanced fraud functionality, include this script on every page, not just the checkout page. This allows Stripe to detect suspicious behavior that may be indicative of fraud as customers browse your website.

The documentation explicitly states:

Asynchronous loading of JavaScript is generally recommended...
...

You can also load Stripe.js using the async or defer attribute on the script tag. Note, however, that with asynchronous loading any API calls will have to be made only after the script execution has finished.

This makes me believe the proposed pull request #2110 would not be desired...
... and that the actual desire would be to load the script "async" / asynchronously.

Loading script "async" / asynchronously

A work around for WordPress not yet having async support attribute quite yet can be found in the "twentytwenty" theme:
https://github.com/WordPress/twentytwenty/blob/master/classes/class-twentytwenty-script-loader.php

https://github.com/WordPress/twentytwenty/blob/6d0a5240af108d02f58ec797fd49b32458a4c698/functions.php#L135-L140
https://github.com/WordPress/twentytwenty/blob/6d0a5240af108d02f58ec797fd49b32458a4c698/functions.php#L208-L209

Although then I question if this plugin's stripe.js / stripe.min.js might need extra validation to ensure the Stripe JS file is loaded before executing?
https://github.com/woocommerce/woocommerce-gateway-stripe/blob/develop/assets/js/stripe.js#L7-L8

Perhaps something like the Stripe NPM implementation?
https://github.com/stripe/stripe-js/blob/master/src/shared.ts#L67

Summary

This doesn't mean that you can't avoid loading the plugin stripe.js / stripe.min.js as per your proposal, just that the https://js.stripe.com script should continue to be loaded, but with an async attribute on the script tag.

@DeanMarkTaylor This seems very reasonable, and well thought out. Thanks a lot.

Having said that, some people may still not want the extra script(s) on every (shopping) page, so this should at least be an option, maybe via a true/false filter.

Thank you all for the reports and the discussion you've got going on here! We apologize for the issue, and — as has been noted above — we are actively working to address the problem.

Like @DeanMarkTaylor rightly pointed out in #2065 (comment) Stripe recommends we load the Stripe JS on as many pages as possible to help combat fraud, which limits the appropriate solutions we can come up with a bit. We're still discussing this but right now we're leaning towards keeping the defaults as they currently are, but offer a filter that will allow merchants to not load the Stripe JS when Payment Request Buttons (Apple Pay/Google Pay) are disabled on the Product and Cart pages.

Merchants will have to weigh the risk of potentially increased rates of attempted/succesful fraud on their stores versus the potential increase in conversion rates from shorter page load times.

We'd be happy to hear more of your thoughts on the matter, so keep them coming 🙂

@reykjalin Filters sound good to me, i think there is no right or wrong in this case, so let the user decide should be the option of choice 🙂

Could also be a setting of the plugin as @galbaras mentioned, a checkbox maybe "Stripe fraud protection" on/off... but filters as of your pull request also do the trick for me.

As long as we're able to disable the scripts, if we don't want them, everything is fine!

I just don't get why everyone is just like "hey let's load some scripts on every pageview, even if we mostly don't need them" sounds a bit like googles recapture approach, let's load it on every page, when a simple hidden honeypot field for forms is exactly as effective and the performance impact is close to zero. But hey that's just my 2 cents....

Anyway, THANKS a lot Kristófer for taking on the issue! 🙂

Disable advanced fraud detection

Regarding not loading not loading Stripe.js (https://js.stripe.com/) on every page...
I could see an new option being called "Disable advanced fraud detection"

This would pass the advancedFraudSignals=false parameter (see documentation here) on the checkout pages and pages where Payment Request Buttons are enabled, and just not load Stripe.js on product pages when Payment Request Buttons is disabled.

<script src="https://js.stripe.com/v3/?advancedFraudSignals=false"></script>

Performance

Although I believe the critical factor here is the async loading for the JavaScript Stripe.js (https://js.stripe.com/).

This is for both user experience and SEO, checking Google Page Insights scores for product pages with "Enable Payment Request Buttons. (Apple Pay/Google Pay)" disabled.

I see "Main-Thread Blocking Time" of over 1 second (1,067 ms) being added to the page load / time to interactive.

But it is true that Stripe is also the largest 3rd party library on the page at 220KiB - so avoiding loading completely unless required for checkout may be preferential for some markets (where data usage / internet performance is a concern).

So, disabling loading of Stripe.js (https://js.stripe.com/) unless needed could be performed by completing both:

• Unchecking "Enable Payment Request Buttons. (Apple Pay/Google Pay)"
• Checking "Disable advanced fraud detection"

I have this issue too on my site, and have had some conversations with WC support staff, who seem to offer only solutions that require turning code of on a page by page basis. This is on a site, where we:
(1) Have no intention of having this "buy now" feature
(2) Have no pages / products on our site with this feature enabled
(3) The Stripe setting: "Enable Payment Request Buttons" is off (and never turned on)

It really is too much I think, to ask a user to disable a feature that the user is NOT using.

Thanks, please fix this!

William

We could just treat the new strip.com script as a new feature. This means that it's disabled by default on existing installations, with the option to enable it.

For simplicity and speed of release, though, we can start with adding async to the script(s) and introducing a filter to disable it/them completely on product pages with no payment request buttons. I think the cart and checkout pages are fine either way, because they are typically very dynamic, un-cached and un-indexed on most sites.

Taking into account my comments regarding async loading implementation here...

I have started a pull request #2118 which is targeting loading the Stripe.JS library asynchronously.

Feel free to code review it over there, the code has not been tested or even executed at-all...
... sharing to save others the effort.

We've merged the filter solution and it should be released this coming Wednesday with Stripe v5.8.0.

I'm still going to re-open this issue so we can talk a bit more about optimal solutions aside from the filters we've just added.

I would also like to add that I do plan on replying to the latest comments and keep this discussion going. I'll get back to you all on that this week 🙂

I have deactivated WooCommerce and our Formidable Forms WooCommerce Addon and I am still seeing the js.stripe.com and m.stripe.network loading? Please make sure to not load these if the plugin is installed but not activated, would be truly grateful. Thank you.

@jenfloods There may be some caching involved. Also, this seems like a new issue (plugin active when WooCommerce isn't), so do some more investigations and start a new issue once you're done.

@reykjalin Thank you for this change. One thing I don't see in it is adding async to the scripts when they are included. This should be the last bit to close off this issue.

If there's page caching and/or page optimisation on the site, clear it. If there's caching on your browser, clear it. Then, gather all the pertinent information, including relevant setup and steps to reproduce the problem, and open a new issue, because your issue is likely different from this one.

A quick TL;DR:

I agree with all of your conclusions: this issue shouldn't be considered resolved until the Stripe JS is loaded asynchronously. Unfortunately this isn't as simple as just adding the async property to the html tag where we load the script. Making this change will take time.

We'll keep working on this, but loading the JS asynchronously will take significantly longer than adding the filters did.

From @galbaras:

We could just treat the new strip.com script as a new feature. This means that it's disabled by default on existing installations, with the option to enable it.

I think there's some miscommunication here, so I just want to clear that up now: the stripe.com script (what I've been referring to as "Stripe JS") is not a new feature; it's necessary to process payments and always has been.

For simplicity and speed of release, though, we can start with adding async to the script(s)

Unfortunately this is not a trivial feature to add as @DeanMarkTaylor pointed out in #2065 (comment).

One thing I don't see in it is adding async to the scripts when they are included. This should be the last bit to close off this issue.

Yes, this is intentional. Like @DeanMarkTaylor pointed out in #2065 (comment) this isn't simple. I go into more detail about that further down in this comment.

From @DeanMarkTaylor:

Disable advanced fraud detection

I would consider this outside the scope of this issue since disabling advanced fraud detection would have a negligible effect on the performance problems reported in this issue; the Stripe JS is still loaded in it's entirety.

I have started a pull request #2118 which is targeting loading the Stripe.JS library asynchronously.

Thank you so much for putting that together!

Unfortunately I don't think this is the most future proof solution we can come up with. The best approach, in my opinion, would be to move the classic shortcode JS out of the assets folder — which is currently bundled using uglify — and into the client folder where it can be bundled using webpack. That way we'll get access to the Stripe JS through an npm package which will take care of loading the script asynchronously for us.

Migrating to webpack has several benefits:

• We don't need to maintain a custom solution to attach the async property to script tags in WordPress.
• This will apply to all inclusions of the Stripe JS automatically.

Both approaches (uglify+custom async and webpack+npm package) would have to deal with the following:

• Fundamentally changing the code dealing with checkout because of the asynchronous loading of the Stripe JS script.
• The change would take a significant amount of time; we'd be changing one of the oldest parts of the codebase that is known to work. Changing the entirety of that part of the code will require new tests so we can be sure we're not breaking any functionality in the process.

There are no benefits to the "uglify+custom async" solution over the "migrate to webpack+npm package" solution.

From @jenfloods:

I have deactivated WooCommerce and our Formidable Forms WooCommerce Addon and I am still seeing the js.stripe.com and m.stripe.network loading?

Just to be clear on one part: the Stripe JS (loaded from js.stripe.com) is necessary to process payments. As such it will be included on all pages where payments can be processed, e.g. the Checkout page, and the Cart and product pages when Payment Request Buttons are enabled.

@galbaras is also right in that this issue is separate from the issue reported here 🙂

If you're seeing the script loaded on product pages or the cart page, read on:

I agree with @galbaras' initial assessment; this is probably related to caching — either through your hosting provider, or in your browser. Try opening the page you're seeing the script loaded on in private browsing mode; that will ensure your browser's cache is empty.

If the problem persists, please open a new issue ☺️

@reykjalin Thank you for the considered reply.

Short term, using a filter to add async doesn't seem like a big deal. Long term, perhaps everyone in this discussion can support https://core.trac.wordpress.org/ticket/51124, which would make adding script parameters easy peasy.

@jenfloods would you be so kind as to open a new issue since what you're facing is unrelated to this issue?

We've merged the filter solution and it should be released this coming Wednesday with Stripe v5.8.0.

@reykjalin Was that Wednesday the 10th or the 17th of November?

Sorry for the confusion around the release date everyone! We were aiming for Wednesday last week (November 10) but decided to delay the release because of issues we discovered while testing the release.

We are currently aiming to release version 5.8.0 tomorrow, November 17.

I am the only one who still have the same problem with the last release ? :/
Or did I just haven't understood something ? 😅

When on 5.5.0 it's fine, but on 5.8.0 I still have these unwanted files on product page 🙄
(Apple/Google pay are disabled, I even removed the product page from the button's location)

No, I'm seeing it as well. If anything the page I am testing on is worse now than it was previously. ApplePay/etc, are all disabled on the site (just CC checkout on the "Checkout" page). No "Buy Now" options. Using the update today (5.8.0)

@ozidrice @wilstart have you enabled the new filters that we've included to disable any extra JS on the cart and product pages?

You can enable them with this snippet:

add_filter( 'wc_stripe_load_scripts_on_product_page_when_prbs_disabled', '__return_false' );
add_filter( 'wc_stripe_load_scripts_on_cart_page_when_prbs_disabled', '__return_false' );

I just added this, and Google page load is still detecting 2 different callouts to
https://js.stripe.com/v3/

I don't see any difference in the page ranking with or without these "add_filter" added.

So, I'd have to see this issue it not fixed. And, while I may not appreciate the difficulties involved in the coding here, it still seems fundamentally flawed that I have to add code to disable a feature I am not using...

Just to confirm my Stripe settings:
Stripe is enabled "Stripe works by adding payment fields on the checkout and then sending the details to Stripe for verification."

In the "Manage" settings for Stripe, "Enable express checkouts" is NOT checked.

Even if this were checked, you have options there to enable this feature on Product pages, Checkout or Cart pages, so you have all the UI to decide whether you need to run this code on Product pages (Cart or Checkout pages as well) don't you?

it still seems fundamentally flawed that I have to add code to disable a feature I am not using...

I would normally agree, but this is not clear cut, considering Stripe recommends it, and it's generally good when the plugin implements Stripe recommendations.

Sadly, I also see both the local and external Stripe assets being included in the page, despite both of the filters being in effect 😞

I'm wondering about this code:

if ( ! in_array( 'product', $prb_locations, true ) ) {
	return apply_filters( 'wc_stripe_load_scripts_on_product_page_when_prbs_disabled', true );
}

Should the filter not apply when product IS in the array? In fact, when I remove the ! from this check, the scripts disappear from the page.

Oops...

Same for the cart check, BTW.

Hi all,

Thank you for reporting the issues you've had with getting the filters to work! I've looked into this, and it seems I made a mistake when creating the filters we introduced in version 5.8.0; they don't take into account whether the PRBs are enabled or not. I've opened a PR to fix the issue in #2179.

There's currently no easy way to work around the issue so we're aiming to get a patch release out today.

I apologize for the inconvenience this has caused and thank you all for your patience!

EDIT: Version 5.8.1 has been released with a fix; the filters should now work as intended.

Should the filter not apply when product IS in the array? In fact, when I remove the ! from this check, the scripts disappear from the page.

@galbaras That would make it so that the scripts can be disabled when the PRB is supposed to be shown on the product page 🙂 The code works as intended when the PRBs are enabled. The mistake I made was not running the filters when the PRBS are disabled (see #2065 (comment)).

I can confirm that v5.8.1 doesn't load Stripe resources on product and/or cart pages when the respective filters are used.

I confirm it too, it's working perfectly with the two filters mentioned earlier
Perfect, thanks a lot ! 💯

@jenfloods Yes you would still need to add them. Cheers

I don't understand this as a fix. You have UI that explicitly lists where to activate Stripe wrt payment on non-checkout pages. Yet we have to add PHP filters as well to disable Stripe code on pages where no payout options are offered to the user?

So, this isn't really a fix from what I understand, but rather a workaround? If so, when will this actually be properly fixed?

Why can't the plugin install these filters itself by default, and then disable them when the user CHECKS the boxes to add these Stripe payment options?

As a "for instance": What happens when I install these filters, and then sometime later I CHECK these payment options expecting to now load Stripe on a product page for a PayNow option? (That is, the UI has PayNow options checked and you have these filters installed)?

The plugin now implements new Stripe recommendations. As such, we should all be loading the Stripe scripts on every page, and the plugin is now compliant with that.

Those of us who think they know better than Stripe, or don't need the extra protection, can now prevent those scripts from loading. The filters only block resource loading when payment buttons are disabled. When they are enabled, the filter will be ignored.

Why? Surely you would expect better than "so and so tells us so" - this is religion, not science, and given the absolutely noticeable and deleterious effects it has on every product page, we deserve a better explanation than "because Stripe says so".

How is this serving our customers who just want to look at what we are offering, but not buying (at least not today) and so there is NO transaction that Stripe is involved in. Yet, each and every product page pays this penalty.

I think you are mis-characterising my concerns. You could even load this "extra protection" on the Cart page, where at least you have some reasonable intention to create an interaction which Stripe (you have chosen to buy something) and the Cart page is still before the ACTUAL checkout page, where in my sites, the payment conditions are being established.

If executing their code had no measurable performance hit, well, I guess I'd be more forgiving. But "because Stripe says so" given that, and without a deeper questioning/pushback from you guys is what I find unacceptable. Please reconsider your position.

This plugin was written precisely to facilitate Stripe payments. On one hand, it "listens" to WooCommerce. One the other, to Stripe. You wouldn't want it to continue using an old API, for example, and this is a kind of new API, which you would have to use if you used Stripe directly.

You now have a way to make things work for you, and the new feature has already rolled out. Let's give it a rest.

People that have implemented the filters, have you noticed any real improvement in performance and/or did you see any issues in fraud protection?

I think no one mentioned this here, but the scripts running from the stripe.com domain also perform several POST requests:

@webdados

People that have implemented the filters, have you noticed any real improvement in performance and/or did you see any issues in fraud protection?

Performance gain is huge, no issues what so ever till now :-)