Add Skeleton loading component to the PMME element on the PDP

[pierorocca]

Description

In https://github.com/Automattic/woocommerce-payments/issues/9107 I note that the previously implemented skeleton loading component for the PMME is now missing. Looking back the record, it may have only been applied to the cart.

Let's add the same skeleton loader to the PMME on the PDP pages to prevent screen shift.

Acceptance criteria

1. Skeleton loader is applied to the PMME element
2. There is no visible screen shift due to the PMME
3. The PMME is painted once available
4. Blocks and shortcode

[FangedParakeet]

@pierorocca, have implemented a potential fix for this in #9166, seeking your validation of the appearance of this approach.

Since the product price container on the PDP contains multiple elements stacked on top of each other, the only way I could perceive to prevent the page from jumping once the PMME has loaded was to give the PMME container a fixed height and space on the page, filling it with the preloading skeleton animation, and then replacing this with the PMME element once it is ready.

Here are a few visual examples...

https://github.com/user-attachments/assets/7ff367d2-02c9-4cf0-8c1b-7735f156a8ab

All three BNPL payment methods available

https://github.com/user-attachments/assets/b89f8239-7e6b-4864-9fc0-b4837edfa125

Two BNPL payment methods available

https://github.com/user-attachments/assets/70ffd036-5e05-439f-aaef-9e7f8a306ded

Single BNPL payment method available

There is a caveat here that the current PMME implementation relies on Stripe to load only the payment methods that will be supported. E.g. since Affirm has a minimum product price of $50 USD, if the product price is less than this amount and all three BNPL payment methods are enabled, Stripe will only return the two payment methods that are supported on this page with the stated price total.

However, the catch here is that by relying on Stripe in this manner, we are not aware of how many payment methods will be presented before the PMME has loaded and moreover Stripe does not inform us which payment methods have been loaded after the PMME is ready either. If we create a fixed space for this element and no BNPL payment methods are available, we will not be aware of this on the client and this empty space will remain.

Here's an example below where only Affirm is enabled, but the total amount is too small for this payment method to be available.

https://github.com/user-attachments/assets/11048baa-68cf-4326-b03f-803ce28cde3f

Empty space when no BNPL payment methods are available

For reference, this is what the PDP page should look like without any BNPL payment methods enabled.

No empty space on PDP

AFAICT, the only way I can think to prevent this would be to calculate which BNPL payment methods should be available on the back-end and provide this information to the PDP prior to loading the page. This could be feasible, but would require a more involved integration than currently provided in #9166.

@pierorocca, eager to hear your thoughts on any and all of the above. I also created a test site if you'd like to play around with this yourself. 🙏

https://scattered-kangaroo.jurassic.ninja demo / Yma21CyeCT29KFqa5wab

[pierorocca]

Your last comment about pre determining makes sense to avoid a blank space. So I think we should hold off on the on page load option so as to not trade off a positive for another negative.

I benchmarked our competitor and a few retail sites and they suffer from similar issue. The big difference I can see is the shifting is smoother, possibly animated. Between the prbs loading at different times and the pmme shifting things it all feels less than elegant. Is there a way to make the shifting smoother in appearance or faster?

[FangedParakeet]

faster

This is challenging. All of the PRBs, PMME, and PDP elements are added to the page independently and asynchronously, so to get these loading in sync would be very tough. Moreover the loading times of the PRBs and PMME are entirely dependent on Stripe, so this is pretty much out of our control.

smoother

There are definitely improvements that could be applied here. Are you able to share any visual reference of desirable competitor behaviour that I might attempt to emulate?

[pierorocca]

Well any site really for smoothness. Lower the playback speed https://github.com/user-attachments/assets/8912b987-f5a8-4550-962e-45a6eaa6b483 and notice the multiple hops up and down. At most 1 would be at parity with sites that include the BNPL offer.

Lighthouse indicates the PMME is non-composited due to an unsupported property on the PMME. Is that a culprit?

[pierorocca]

Purple.com has a pretty decent smooth flow https://purple.com/mattresses/plus

AmericanEagle.com has a similar approach to what you proposed above. They've created some dedicated space that will or won't get filled depending if an offer is available. Reconsidering....

[pierorocca]

To recap I'm seeing on page load: shift up, shift down, shift up, shift down. On web examples: shift down.

WooPay button skeleton loads shifting screen up, the screen shifts down when WooPay button is fully loaded. Then PMME shifts screen up and then down once rendered.

Ideal state here is a single shift down once the PMME offer is returned.

[FangedParakeet]

Ideal state here is a single shift down once the PMME offer is returned.

@pierorocca, have been fiddling with this a lot more today. I can't do much about the PRBs and other elements on the page, but I have managed to get the PMME's introduction a lot more seamless. Thoughts?

https://github.com/user-attachments/assets/03e2e0f9-44d1-49c6-a52e-59a3a89d5d61

Feel free to play around with it on my same ol' test site.

https://scattered-kangaroo.jurassic.ninja/ demo / Yma21CyeCT29KFqa5wab

[pierorocca]

Feels a lot better! Thanks so much for the persistence on this given current constraints. Let's go with this as a step upgrade and open up an issue for whatever ideas you have for a proper refactor.

[pierorocca]

That bread looks delicious. @FangedParakeet one thing I've noticed post rollout is that when there's no offer, there's a huge whitespace gap where we've reserved the space for the offer. Is there a way to achieve the benefits implemented in https://github.com/Automattic/woocommerce-payments/issues/9107 without having too much of the screen shift down when an offer is available and not take up the space when there's no offer?

[mdmoore]

p1726566945164299-slack-CGGCLBN58 Following up on the conversation above, the PMME and skeleton are being loaded on PDPs even when there's no offer available. This leads to a loader that, when removed, leaves dead space on the page. This was brought up as a problem with minimum order amount not being met and solved here. The same type of solution needs to be applied to all BNPL payment method requirements so that no skeleton or dead space appear on the page, and no elements are shifted.