• Resolved polina92

    (@polina92)


    Hi,

    I did not select the options to have google or apple pay on product pages. Though, the impact of this stripe plugin on page speed is awful:

    https://snipboard.io/sC2h3A.jpg

    https://snipboard.io/pqeCi1.jpg

    Impose the load of 800k is a non-sense.

    Stripe mentions that the scripts shall be loaded on all pages to prevent fraud. Why not in certain countries, but in Europe, we have 3D secure, so why add a layer? All the more that each site can have 1 or more security plugins.

    Why isn’t there the possibility to have stripe scripts and css only loaded on cart and checkout pages?

    Waiting for your feedback

    Regards

Viewing 10 replies - 1 through 10 (of 10 total)
  • Plugin Author Payment Plugins

    (@mrclayton)

    Hi @polina92

    I did not select the options to have google or apple pay on product pages. Though, the impact of this stripe plugin on page speed is awful:

    The plugin is designed to only load Stripe on product pages if you have Apple Pay or GPay enabled on those pages. If you are certain that you don’t have those payment options enabled then check if you have the mini cart payment options enabled.

    The mini-cart is provided by WooCommerce or other plugins is typically available on all frontend pages and would result in the js.stripe.com script being loaded.

    Impose the load of 800k is a non-sense.

    The script you’re referring to is the js.stripe.com script which is required by Stripe and is not specific to this plugin. Regardless of what Stripe plugin you use, that script will be required.

    Stripe mentions that the scripts shall be loaded on all pages to prevent fraud. Why not in certain countries, but in Europe, we have 3D secure, so why add a layer? All the more that each site can have 1 or more security plugins.

    Our Stripe plugin only loads js.stripe.com on pages for which you have a Stripe payment method enabled.

    Why isn’t there the possibility to have stripe scripts and css only loaded on cart and checkout pages?

    That’s exactly how the plugin is designed, it only loads the necessary payment scripts on pages for which you have a payment method enabled. If you’re seeing something different, you might be using a cache plugin or minification plugin that’s grouping scripts together in a common file and loading that. As previously mentioned, make sure you don’t have Apple Pay or GPay enabled for the mini-cart.

    Kind Regards

    Thread Starter polina92

    (@polina92)

    Hello,

    Thank you for this comprehensible and detailed feedback.

    This is your plugin description: “Offer Google Pay, Apple Pay, and Stripe’s Browser payment methods on product pages, cart pages, and at the top of your checkout page.” So, I did it.

    And iwhen made so, the “price” is 800k loaded, as you saw, with few seconds of render-blocking. And effectively, if those Apple & Google pay are not activated, it’s back to “normal”, ie stripe is not loaded on product pages and archives, page speed is much better, and thus not render blocking, and thus not irritating for visitors. I understand that those 800k are not related to the plugin, but it’s HUGE. Maybe should make people aware of it?

    I have http/2, so no need to group scripts. And since js.stripe.com is a 3rd party script, it’s not managed by my cache or any minification “tool”.

    I have mini-cart. So, maybe the rightest thing to do would be to have the option to only activate Apple and Google pay on checkout page?

    Kind regards

    Plugin Author Payment Plugins

    (@mrclayton)

    So, maybe the rightest thing to do would be to have the option to only activate Apple and Google pay on checkout page?

    Yes, if you’re concerned with page load speeds, you can configure Apple Pay and GPay to just be available on your checkout page.

    I understand that those 800k are not related to the plugin, but it’s HUGE. Maybe should make people aware of it?

    Everyone’s page load speeds are different because there are many factors at play. That is why we load all the plugin scripts and js.stripe.com in the footer of the site, so the scripts don’t interfere with the actual rendering of page content. The visual rendering of your site is thus much faster than what’s reported on a page analyze.

    Kind Regards

    Moderator Steven Stern (sterndata)

    (@sterndata)

    Volunteer Forum Moderator

    @polina92 Moderator note: I’ve removed your last reply here as it was a personal attack. I’m sure you can find a way to ask your questions without insulting anyone.

    Thread Starter polina92

    (@polina92)

    With apple pay and google NOT activated at all, I have Google complaining about the 700k of JS

    https://snipboard.io/2WYnDt.jpg

    Of course, Stripe is also a render-blocking 3rd party, since they do not enable to load the scripts on site.

    All in all, the changes that you proposed are ineffective; 850k in total are still loaded by your plugin, negatively and hugely impacting page speed and page load.

    Second point: when google pay is deactivated, could you please precise why stripe is connecting to google pay?

    https://snipboard.io/NIzxLU.jpg

    Plugin Author Payment Plugins

    (@mrclayton)

    With apple pay and google NOT activated at all, I have Google complaining about the 700k of JS

    I was able to review your site since one of your screenshots had the url. You have the Payment Request Gateway enabled which supports GPay per the documentation on the gateway settings page. That’s why js.stripe.com and GPay scripts are loading.

    As you can see in the screenshot of your product page, GPay is being loaded via the Payment Request Gateway. If you don’t want that behavior, you will need to configure the Payment Request Gateway to not load on product pages.

    Second point: when google pay is deactivated, could you please precise why stripe is connecting to google pay?

    You may have the Google Pay Gateway disabled, but you have the Payment Request Gateway enabled which has a GPay implementation.

    Thread Starter polina92

    (@polina92)

    ???

    Payment request is not activated:

    https://snipboard.io/SUId8C.jpg

    Afterpay is not activated:

    https://snipboard.io/i3VbLF.jpg

    They are adding themselves on product pages:

    https://snipboard.io/XHvnws.jpg

    Without consent.

    The link with google or apple servers, out of checkout / payment makes your plugin not compliant with GDPR. And probably the same issue in several US states.

    Plugin Author Payment Plugins

    (@mrclayton)

    Hi @polina92

    I reviewed your site again and see that GPay is no longer loading on your product pages and you just have the Stripe card gateway enabled on your checkout page. It appears you were able to implement our feedback and disable GPay on product pages.

    The link with google or apple servers, out of checkout / payment makes your plugin not compliant with GDPR. And probably the same issue in several US states.

    That is not an accurate statement regarding GDPR. However, if you believe our solution is not compliant then my recommendation would be to try other Stripe plugins and see if they provide the functionality that you’re looking for.

    Kind Regards

    Thread Starter polina92

    (@polina92)

    why this?

    https://snipboard.io/XHvnws.jpg

    If a visitor refuses cookies / tracking, then, there shall be no connection which enables the tracking. What includes for instance Google fonts, that have to be on server side in such a case. If Gpay is implemented on product pages, what is the good reason to call Google before checkout, and even anywhere before payement?

    Thread Starter polina92

    (@polina92)

    No answer.

    So, you agree that your plugin has “bugs” (for instance, what is written as “activated” on product pages can be not activated in reality), and that it’s illegal in Europe.

    In addition to weight 850k.

    Cheers

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘Awful impacts on site speed’ is closed to new replies.