Stripe Plugin loads unnecessary resources

[wilstart]

The full details of this can be found here:
#2065

The original issue has not been fixed, but a rather ugly, and potentially conflicting "workaround" has been implemented.

Concerns raised about the issue have been met with "because Stripe said so", which given the deleterious effect of their proposal is unacceptable to me. Clearly the developer does not understand why this is required, and so is prepared to propagate this problem throughout any website that uses this plugin gateway, censoring any further discussion on the issue because he has closed the report.

So, I'm opening this thread in the hope that others will feel we have a right to at least understand WHY this huge performance hit is deemed acceptable and has to be propagated to all users of this plugin.

Thank you for reading,

[lkraav]

As I thought, main reason for loading stripe.js everywhere is better fraud detection, see https://stripe.com/docs/js/including (or so they claim).

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.

Depending on your specific site, it may or may not be optimal.

I have not yet measured the performance impact of their script, but am not loading it everywhere thus far.

[wilstart]

My product pages take twice as long to load as other pages on the site which have much heavier payloads. with nearly 1sec spent in calls out to stripe - and from the previous comments many others are seeing this with similar problems.

Ok - so we are on a product page, with no "pay now" buttons. What happens when Stripe "detects suspicious behaviour that maybe indicative of fraud".

Given the MAY in that sentence, this seems like the possibility of false positives is NON-zero. So, what action do they take? How do they ensure their diagnosis is ABSOLUTELY correct?

I understand fraud is a problem, but this seems a bridge too far to my mind particularly given the performance cost.

[lkraav]

Valid questions, but it may make more sense to discuss this at https://github.com/stripe/stripe-js

[supernrm]

It's ridiculous to load it on every page. Not everyone is interested in fraud detection and giving free data to Stripe. That is quite high cost for it. This should be an option.

[WhoopDav]

Agreed. It is rediculous that Stripe says it needs to load these JS page blocking scripts on every page for "Fraud Detection". Stripe managed fine their fraud protection system before, without loading their JS scripts on every page.

Today with so much focus on lowering page speed, how on earth do they think they can get away with this, adding so many scripts to pages where there are not even their payment buttons loading.

If it is a choice between leaving Stripe and using the payment servces of another company, and fixing the page speed, I am leaning towards leaving Stripe. I have written to their support, but I am not hopeful of a positive reply.

[skullo27]

We use a great plugin called Perfmatters, it is a performance plugin for WP that has a load of things, but what is relevant here is the ability to block unnecessary scripts from loading on whatever page you like or globally etc.

My question is, given that I "can" stop this script from loading site-wide, should I? I mean, does it affect the actual checkout with stripe or payment request buttons at all if I still load on those pages? I presume not?

I guess what I want to know is, will the gateway still work like normal if I block the script on the product page (excluding /cart/ and /checkout/?

thanks

[WhoopDav]

Hi @skullo27

The answer which you will get back from Stripe (I believe) is that you need the scripts to load on every page as without it their fraud detection does not work as it should. However I have a similar plugin to yours and I disabled all these JS scripts from Stripe (apart from on the Checkout, Basket, order-success pages etc)... The plugin still was able to take payments with no issue at all. The only thing that did not work is their call-back function, but you could possibly get that to work by enabling al their scripts on the call back URL. I did not check this.

I ended up keeping all the scripts loading on every page, as I did not want any issues with potential fraud problems if ever there was a case which is unlikely for our shop. However, I would hope Stripe fixes this in an update and removes this excessive bulk which is negatively affecting page speed scores.

[skullo27]

Thanks for the info @WhoopDav. I think I will probably leave active for now but it seems ridiculous they need this kind of overhead on sites when they already have the Radar rules and other fraud prevention stats. I do not see how they will draw much from anything other than product, cart and checkout pages.

It seems many devs do not care for page speed when building their plugins!

[WhoopDav]

Totally agree

[chrism245]

13076882-hc

[kaushikasomaiya]

5291826-zen

[dougaitken]

Hi all,

I appreciate some time has passed since the original comment, thanks for your patience.

I'd be interested to find out the difference people are seeing when product page loads with and with the Stripe plugin active. Also if Payment Request buttons (Apple Pay etc) are enabled or not.

Thanks,

[pjrobertson]

Hi @dougaitken

I came across this issue after trying to debug my Woocommerce product pages loading slowly. Lighthouse reports showed the stripe.js code blocking the main thread for 200ms, the script load also delays page load. I have tried enabling/disabling the 'express checkout' option and also enabling/disabling express checkout on 'Product' pages, bu the script still loads.

I understand Stripe's fraud protection issues, but this is damaging our web page performance for their own benefit.

---

Edit: It's worth noting that a fix has been implemented, although it's off by default. See #2065

Add this to your functions.php file;

add_filter( 'wc_stripe_load_scripts_on_product_page_when_prbs_disabled', '__return_false' );

[thuautp]

6500246-zen

[github-actions]

Hi,
This issue has gone 150 days (5 months) without any activity. This means it is time for a check-in to make sure it is still relevant. If you are still experiencing this issue with the latest version, you can help the project by responding to confirm the problem and by providing any updated reproduction steps.
Thanks for helping out.

[github-actions]

This issue has gone 180 days (6 months) without any activity.